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This  paper  presents  the  set  of  characterlstfcs  needed  for 
a  common  prc^rammlng  language  of  embedded  computer  systems 
applications  in  the  DoD.  In  addition,  it  describes  the  back¬ 
ground,  purpose,  and  organization  of  tne  DoD  Common  Programming 
Language  efforts.  It  reviews  the  issues  considered  in  developing 
the  needed  language  characteristics,  explains  how  certain 
trade-offs  and  potential  conflicts  were  resolved,  and  discusses 
the  criteria  used  to  ensure  that  any  language  satisfying  the 
criteria  will  be  suitable  for  embedded  computer  applications, 
will  not  aggravate  existing  software  problems,  and  will  be  suit¬ 
able  for  standardization. 
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PREFACE 

This  paper  was  prepared  for  the  Office  of  the  Director  of 
Defense  Research  and  Engineering  (Electronics  and  Physical 
Sciences)  as  Part  1,  Software  Research  and  Development,  of 
Task  T-36  (revised),  "Evaluations  of  Options  in  Electronic 
Technology".  Task  T-36  provides  Independent  evaluations  of 
selected  areas  of  electronic  technology  where  the  Services  are 
pursuing  different  technical  approaches  to  similar  problems. 

Portions  of  this  document  have  appeared  in  "Programming 
Language  Commonality  in  the  Department  of  Defense",  by  D.  A. 
Fisher,  Defense  Management  Joumalf  Vol.  11,  No.  (October 

(1975),  pp.  29-33. 


PrecR&ig  page  blank 


vll 


CONTENTS 


Abstract 


ill 


Acknowledgment 


V 


Preface 


vll 


Summary 


1 


A. 


B. 


C, 


Background 

1.  The  DoD  Software  Problem 

2.  Character  of  the  DoD  Software  Environment 

3.  Programming  Languages  In  the  DoD 

The  Common  Programming  Language  Effort  of  the  DoD 

1.  Background 

2.  Organization  and  Method 
Findings 


2 

2 

3 

6 

7 

7 

9 

11 


I.  Introduction  17 

A.  The  Problem  IB 

1.  Software  Costs  18 

2.  Programming  Language  20 

3.  Lack  of  ComiTionality  20 

H.  Common  Language  23 

5.  Morse  Code  Experiment  2^ 

B.  Purpose  of  the  Common  Programming  Language  27 

Effort 

I.  A  Common  Programming  Language  28 

2.  High-Order  vs.  Low-Level  Programming  29 

Language 

C.  Other  Issues  33 

1.  Scope  33 

2.  Application-Oriented  Languages  33 

3.  Effect  on  Software  Expenditures  3^ 

U.  Effect  on  Software  and  Programming  36 

Language  RiD 

5.  Direct  Coses  of  Common- Language  Effort  36 

6.  Standardization  37 

7.  A  New  Language  38 

8.  Size  39 

9.  Priorities  ^0 

10.  Consistency  ^0 

11.  Committee  Design  ^0 

12.  Nontechnical  Needs  Ml 

ix 


Preceding  page  blank 


II.  Major  Conflicts  in  Criteria  and  Needed  ^3 

j  Characteristics 

V  A.  Simplicity  vs.  Specialization  ^3 

B.  Programming  Ease  vs.  Safety  from  Programming  ^5 

Errors 

C.  Object  Efficiency  vs.  Program  Clarity  and  ^6 

Correctness 

D.  Machine  Independence  vs.  Machine  Dependence  ^7 

E.  Generality  vs.  Specificity  ^9 

III.  The  Most  Pressing  Software  Problems  51 

A.  Responsiveness  52 

5.  Reliability  52 

C.  Flexibility/Maintainability  53 

D.  Excessive  Cost  5^ 

E.  Timeliness  55 

F.  Trrnsferability  55 

G.  Efficiency  56 

IV.  Language  Design  Criteria  59 

A.  Criteria  to  Satisfy  Specialized  Application  60 

Requirements 

1.  Flexibility  in  Software  Design  Criteria  60 

2.  Fault-Tolerant  Programs  60 

3.  Machine-Dependent  Programs  6l 

.  Real-Time  Capability  6l 

5.  System-Programming  Capability  6l 

6.  Data  Base  Handling  Capability  62 

7.  Numeric  Processing  Capability  62 

B.  Criteria  Addressing  Existing  Software  Problems  62 

1.  Simple  Source  Language  62 

2.  Readable/Understandable  Programs  6^ 

3.  Correct  Translator  6^ 

Error-Intolerant  Translator  6^^ 

5.  Efficient  Object  Code  66 

C.  Criteria  to  Assure  a  Common  Programming  67 

Language  Product 

1.  Complete  Source  Language  6/ 

2.  Wide  Applicability  68 

3.  Implementable  68 

5.  Static  Design  68 

5.  Reusability  70 

6.  A  Pedagogical  Language  70 

V.  The  Needed  Characteristics  71 

A.  Data  and  Types  72 

B.  Operations  76 

C.  Expressions  and  Parameters  8l 

D.  Variables,  Literals,  and  Constants  86 

E.  Definition  Facilities  91 


X 


F.  Scopes  and  Libraries  95 

G.  Control  Structures  99 

H.  Syntax  and  Comment  Conventions  IO6 

I.  Defaults,  Conditional  Compilation,  and  II3 

Language  Restrictions 

J.  Efficient  Object  Representations  and  117 

Machine  Dependencies 

VI.  Characteristics  Needed  for  Other  Aspects  of  the  123 

Common-Language  Effort 

A.  Program  Environment  12^4 

B.  Translators  127 

C.  Language  Definition,  Standards,  and  Control  132 

References  137 

Appendix  A-1 


xi 


SUMMARY 


This  document,  which  reports  the  work  of  the  author  in  sup¬ 
port  of  the  DoD  Higher  Order  Language  Working  Group,  is  intended 
to  provide  the  Services  with  the  necessary  technical  guidelines 
to  achieve  their  goal  of  programming  language  commcncLlity  for 
embedded  computer  applications  In  the  Department  of  Defense.* 

It  provides  background  on  the  software  and  programming  language 
problems  In  the  DoD,  presents  the  language  design/selection 
criteria  used  to  guide  evaluation  of  technical  characteristics, 
and  Identifies  the  characteristics  needed  for  the  common  language. 

The  IDA  effort  provided  the  background,  analysis,  and  evalu¬ 
ations  necessary  to  reconcile  the  diverse  and  sometimes  conflict¬ 
ing  perceived  needs.  It  Included  examination  of  the  purpose  and 
expectations  for  the  Higher  Order  language  effort,  review  of  sev¬ 
eral  technical  and  managerial  Issues  in  selecting  a  common  pro¬ 
gramming  language,  and  analysis  of  some  Important  trade-offs  in 
the  design/selection  criteria  and  In  the  choice  of  language  char¬ 
acteristics.  The  selected  choices  were  subjected  to  Intensive 
critical  review  by  the  language's  potential  users  and  others  con¬ 
cerned,  In  an  attempt  to  illuminate  the  Issues  In  a  comprehensive 
way.  This  document  represents  the  degi-ee  to  which  this  has  been 
done . 


An  embedded  computer  system  Is  physically  Incorporated  Into  a 
larger  system  '•’hose  primary  function  Is  not  data  processing 
(e.g.,  electromechanical  system  combat  weapon  system,  tactical 
system,  aircraft,  ship,  missile,  spacecraft,  command,  control, 
and  communication  systems)  Is  Integral  to  that  system  from  a 
design,  procurem.ent ,  and  operations  viewpoint,  and  generally 
Includes  lnform.ation,  control  signals  and  computer  data  In 
Its  output. 
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A.  BACKGROUN[. 


The  problems  of  digital  computer  software  are  complex  and 
poorly  understood.  Although  there  are  many  widely  recognized 
symptoms,  the  underlying  problems  are  not  well  delineated  and 
there  are  few  useful  quantitative  measures  for  assessing  either 
the  importance  of  perceived  problems  or  the  effectiveness  of 
proposed  solutions. 

1 .  The  DoD  Software  Problem 

Some  important  software-related  problems  are  listed  below. 

Each  item  describes  a  class  of  unrealized  expectations  about  the 
development  or  maintenance  of  DoD  software.  These  "problems” 
are  unique  neither  to  software  nor  to  the  military,  but  unlike 
electronic  equipment,  software  has  no  Inherent  physical  constraints 
to  limit  expectations. 

•  Responsiveness .  Computer-based  systems  often  do  not  meet 
user  needs.  This  may  reflect  poor  specification  of  re¬ 
quirements,  poor  system  performance,  or  lack  of  flexibil¬ 
ity  in  the  software. 

•  Reliability .  Software  often  falls.  Both  the  probability 
of  software  faults  and  errors  and  the  effects  of  such 
errors  on  system  operation  must  be  reduced. 

•  Cost .  Software  costs  are  seldom  predictable  and  are  often 
perceived  as  excessive.  Life-cycle  costs  are  given  insuf¬ 
ficient  consideration  during  software  development. 

•  Modifiability .  Software  maintenance  is  complex,  costly, 
and  error  prone,  and  the  difficulty  in  modifying  software 
increases  the  need  for  duplicative  software  development. 

®  Timeliness .  Software  is  often  late  and  frequently  deliv¬ 
ered  with  less-than-promlsed  capability.  There  are  no 
accurate  methods  for  predicting  software  production  times. 

•  Transferability .  Software  from  one  system  is  seldom  used 
in  another,  even  when  similar  functions  are  required. 
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•  Efficiency.  Software  development  efforts  do  not  make 
optimal  use  of  the  resources  (processing  time  and  memory 
space)  involved,  especially  In  embedded  computer  appli¬ 
cations  with  their  real  time  constraints  and  often  lim¬ 
ited  hardware  resources. 

Although  the  above  list  is  consistent  with  the  findings  of 
many  DoD  In-house  and  contractor  studies  of  the  software  problem 
(Ref.  1),  Its  elements  represent  only  perceptions  of  the  problem, 
and.  In  most  cases,  are  not  or  cannot  be  substantiated  by  quanti¬ 
tative  data.  For  example,  software  costs  are  thought  to  be  ex¬ 
cessive,  but  actual  software  costs  are  largely  unknown  and  there 
Is  little  evidence  that  they  can  be  reduced. 

Obvious  solutions  are  not  necessarily  the  best.  Efficiency 
Is  Important,  and  although  any  computer  program  can  be  rewritten 
to  run  faster  or  to  use  less  memory  space,  more  optimal  coding 
may.  In  fact,  result  in  higher  total  costs.  There  Is  evidence 
that  software  costs  grow  exponentially  with  attempts  to  Increase 
hardware  utilization,  while  hardware  costs  for  increased  speed 
or  memory  capacity  grow  linearly,  or  less.  Thus,  if  the  physi¬ 
cal  constraints  on  the  hardware  can  be  met,  the  least  costly 
solutions  may  lie  with  more  capable  but  underutilized  hardware. 

2 .  Character  of  The  DoD  Software  Environment 

Software  Is  becoming  increasingly  costly  to  the  DoD.  Digi¬ 
tal  computer  software  costs  In  the  DoD  in  1973  were  estimated 
(Ref.  2)  at  $3  billion  to  $3.5  billion  annually.  Between  1968 
and  1973,  there  was  a  51  percent  increase  In  total  direct  cost 
of  DoD  computer  systems  (including  both  hardware  and  software) 
reported  under  the  Brooks  Bill  (Public  Law  89-306,  October  1965). 
These  Increases  occurred  even  though  there  were  drastic  reduc¬ 
tions  In  both  unit  and  total  costs  of  computer  hardware  and  fewer 
systems  were  reported  In  1973*  The  increased  costs  of  computer 
software  may  reflect  a  combination  of  factors.  Including  (a)  the 
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trend  toward  more  automation  and  Increased  use  of  computers, 

(b)  the  greater  complexity  of  software  resulting  from  Increased 
expectations  and  expanded  requirements  generated  by  Improved 
hardware  eind  software  technology,  and  (c)  rising  personnel  costs. 

The  major  problems  of  DoD  software  are  associated  with  em¬ 
bedded  computer  systems.  Embedded  computer  system  software  In¬ 
cludes  all  software  which  Is  Integral  to  a  larger  military  system 
or  weapon,  including  tactical  weapons  systems,  communications, 
command  and  control,  avionics,  simulation,  test  equipment,  train¬ 
ing,  and  systems  programming  applications.  It  also  Includes  any 
software  which  supports  the  design,  development,  or  maintenance 
of  such  systems.  As  a  general  rule,  embedded  computer  software 
Is  software  for  any  DoD  computer  hardware  which  Is  not  reported 
under  the  General  Management  Category  of  the  Brooks  Bill.  DoD 
software  which  Is  not  In  the  embedded  computer  software  category 
Is  used  primarily  In  data  processing  and  scientific  applications. 

The  majority  of  software  costs  In  the  DoD  are  associated 
with  embedded  computer  systems  (see  Fig.  1).  Embedded  computer 
software  often  Is  large  (50,000  to  100,000  lines  and  greater). 

Is  long-lived  (10  to  15  years).  Is  subject  to  continuing  change 
(annual  revisions  of  the  same  magnitude  as  the  original  software 
size),  a-id  must  conform  to  physical  and  real  time  constraints  of 
the  associated  system  hardware  and  requirements.  Scientific  ap¬ 
plications  require  the  largest  and  most  visible  computers  In  DoD 
and  may  use  a  significant  portion  of  the  total  computing  power, 
but  they  represent  only  about  five  percent  of  software  costs. 
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FIGURE  1.  Breakdown  of  Estimated  $3  Billion  Annual  DoD  Computer  Software 
Costs  [Derived  from  figures  in  CCIP-85  and  in  P-1046  (Refs.  1 
and  2)3 
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There  are  at  least  i<50  general-purpose  languages  and  dia¬ 
lects  currently  used  In  the  DoD,  but  it  Is  not  known  whether 
the  actual  number  Is  500  or  1500.  With  few  exceptions,  the  only 
languages  used  in  data  processing  and  scientific  applications 
are,  respectively,  COBOL  and  FORTRAN.  A  larger  number  of  pro- 


for  embedaed  computer  software  may  reflect  an  unfounded  ^5ptl- 
mlsm  that  software  problems  would  disappear  if  only  there  were 
a  language  better  suited  to  the  task  at  hand.  However,  tne 
little  available  evidence  Indicates  that  the  major  payoffs  will 
come  from  better  programming  methods  and  techniques,  more  soft¬ 
ware  commonality,  and  more  useful  and  easily  accessible  soft¬ 


grammlng  languages  are  used  in  embedded  computer  systems  appll- 
The  continued  proliferation  cf  programming  languages 


ware  tools  and  aids. 


There  are  a  number  of  widely  held  perceptions  about  the  111 
effects  of  the  lack  of  prograimmlng  language  commonality  In  the 
DoD.  Although  these  111  effects  can  be  substantiated  only  by 
examples,  and  their  true  extent  Is  unknown,  they  have  provided 
much  of  the  Incentive  for  the  common-language  effort.  The  lack 
of  programming  language  commonality  In  DoD  embedded  computer 
applications  may: 

•  Require  duplication  In  training  and  maintenance  for  the 
languages,  their  compilers,  their  associated  software 
support  packages,  and  of  all  the  common  functions  needed 
In  the  application. 

•  Minimize  communication  among  software  practitioners  and 
retard  technology  transfer. 

•  Result  In  support  software  being  project-unique  and  tie 
software  maintenance  to  the  original  developer. 

•  Diffuse  expenditures  for  support  and  maintenance  soft¬ 
ware  so  only  the  most  primitive  software  aids  are  de¬ 
veloped,  but  repeatedly. 

•  Limit  the  applicability  of  new  support  software  and  tech¬ 
niques. 
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•  Create  a  situation  In  which  the  adoption  of  an  existing 
language  by  a  new  pr^'.lect  Is  often  r^ore  risky  and  less 
cost-effective  (at  least  during  development)  than  de¬ 
veloping  a  new  programming  language  specialized  to  the 
project . 

On  the  other  hand,  programming  languagas  are  the  primary 
means  of  Introducing  new  programming  methods,  tools,  techniques, 
and  greater  automation  Into  software  development  and  maintenance 
processes.  Consequently,  there  should  be  periodic  review  of  the 
common  language(s)  for  possible  upgrading  or  replacement  to  ac¬ 
commodate  demonstrable  and  useful  advances  In  software  technology 
and  methods.  Also,  there  Is  no  practical  way  to  reimplement 
existing  software,  so  even  If  all  language  proliferation  were 
stopped.  It  would  be  10  to  15  years  before  the  existing  languages 
could  be  dropped. 

B.  THE  COMMON  PROGRAMMING  LANGUAGE  EFFORT  OF  THE  DoD 
1 .  Background 

During  197^,  elements  in  each  of  the  Military  Departments 
Independently  proposed  the  adoption  of  a  common  programming  lan¬ 
guage  for  use  In  the  development  of  major  defense  systems  within 
their  own  departments  and  undertook  efforts  to  achieve  that  goal. 
Those  efforts  Included  the  Army  "Implementation  Language  for  Real- 
Time  Systems"  study,  the  Navy  CS-^  effort,  and  the  Air  Force  "High 
Order  Language  Standardization  for  the  Air  Force"  study. 

In  January  1975,  the  Director,  Vefense  Research  and  Engi¬ 
neering  (DDR&E),  In  a  memo  to  the  Assistant  Secretaries  of  the 
Military  Departments  for  RiD,  noted  the  multiple  benefits  of  a 
single  common  language  for  military  applications  (Ref.  3).  He 
requested  Immediate  formulation  of  a  joint  Service  program  to 
assure  maximum  useful  software  commonality  In  the  DoD.  A  working 
group  was  formed  from  official  representatives  of  the  Military 
Departments  and  chaired  by  DDR&E.  Representatives  from  0A3D-T&L, 
OASD-Comptroller ,  and  the  Defense  Communications  Agency,  and  NASA 
also  participated.  The  author  acted  as  technical  advisor. 
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A  major  step  in  achieving  software  commonality  will  be  the 
adoption  of  a  very  few  (possible  only  one*)  common  programming 
languages  to  be  used  for  the  design,  development,  support,  and 
raaintencU’.ce  of  all  digital  computer  software  for  embedded  com¬ 
puter  applications  in  the  DoD.  Such  a  language  would  need  to 
encompass  the  specialized  needs  of  the  intended  DoD  software 
applications,  be  able  to  support  best  current  software  practice, 
be  complete  and  unambiguous  in  its  definition,  and  be  capable 
of  supporting  enforceable  standards.  As  a  short-term  effort, 
it  will  have  to  be  practically  and  efficiently  implementable 
with  existing  software  technology. 

Programming  languages  are  neither  the  cause  of  nor  the  so¬ 
lution  to  software  problems,  but  because  of  the  central  role 
they  play  in  all  software  activity,  they  can  eicher  aggravate 
existing  problems  or  simplify  their  solution.  Adoption  of  a 
single  common  language  alone,  will  not  make  software  more  re¬ 
sponsive  to  user  needs,  reduce  software  design  or  programming 
errors,  make  software  more  reliable,  reduce  software  costs, 
simplify  test  and  maintenance,  increase  programmer  productivity. 
Improve  object  efficiency,  or  reduce  untimely  delivery  of  soft¬ 
ware. 

However,  adoption  of  an  appropriate  common  programming 
l«mguage  may  remove  many  of  the  barriers  to  solving  software 
problems.  It  may  lessen  the  communications  barriers  which  pre¬ 
vent  new  systems  from  using  the  experiences  of  earlier,  similar 
systems  to  full  advantage.  It  may  reduce  the  burden  and  delay 
of  designing,  building,  and  maintaining  languages,  compilers, 
support  software,  and  software  tools  for  individual  projects 
and  permit  them  to  be  concentrated  on  their  applications.  It 
may  remove  the  dependence  on  original  software  vendors  and  in¬ 
crease  competition.  It  may  encourage  development  of  better  tools 
both  through  pooling  of  costs  within  the  DoD  and  by  creating  a 

larger  market  for  independently  developed  software  tools  and  aids 

1 - 

For  convenience  hereafter,  we  use  the  singular  to  refer  to  the 

minimum  number  of  languages  needed. 


The  scope  of  the  common  programming  language  effort  has 
been  limited  to  applications  subsumed  by  embedded  computer  sys¬ 
tems  because  there  are  several  software  problems  unique  to  em¬ 
bedded  computer  systems,  because  such  systems  represent  the 
majority  of  software  costs  In  the  DoD,  because  they  are  the  major 
application  areas  In  which  there  Is  no  widely  used  language 
currently,  because  they  represent  the  applications  with  tht 
most  pressing  software  problems,  and  because  they  ag^e  the  only 
area  In  which  most  programming  Is  currently  done  In  assembly  or 
machine  languages.  The  diversity  of  functions  performed  by  em¬ 
bedded  computer  systems,  however,  guarantees  that  the  most  char¬ 
acteristics  needed  In  data  processing  and  scientific  programming 
will  be  Included  In  the  requirements  for  a  embedded  computer  sys¬ 
tem  language. 

Embedded  computer  systems  software  tends  to  be  large  (In¬ 
volving  many  programmers  working  together),  and  to  be  long-lived 
(with  several  turnovers  of  software  personnel  during  Its  life¬ 
time).  Run-time  efficiency  Is  Important  because  of  real-time 
constraints.  Delayed  deliveries  can  be  extremely  expensive  In 
Indirect  costs  from  loss  In  the  useful  life  of  the  military 
systems  In  which  the  software  Is  embedded.  Programming  errors 
can  have  catastrophic  consequences. 

2 .  Organization  and  Method 

The  needed  language  characteristics  will  be  used  as  quali¬ 
fication  criteria  for  candidate  languages.  They  attempt  to  ad¬ 
dress  each  major  Issue  associated  with  the  selection  of  a  com¬ 
mon  language,  and  where  there  Is  a  definitive  reason,  the  char¬ 
acteristic  prescribes  a  resolution  to  the  Issue.  In  other  cases, 
they  provide  only  guidelines  or  decision  criteria. 

The  needed  characteristics  were  developed  through  a  9-month- 
Icng  feedoack  process  Involving  the  Working  Group,  IDA,  many 
commands  and  offices  within  the  Military  Departments,  and  several 
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outside  organizations.  These  included  all  potential  users  who 
could  be  identified.  In  all,  over  200  Individuals  from  85  DoD 
organizations,  26  industrial  contractors,  I6  universities,  and 
7  other  organizations  participated. 

The  effort  to  identify  the  needed  technical  characteristics 
for  the  common  DoD  programming  language  began  with  a  meeting 
of  technical  personnel  representing  the  Military  Departments  at 
IDA  on  April  ^  to  11,  1975.  That  meeting  generated  a  trial  set 
of  language  characteristics  which  was  intentionally  vague  and 
inconsistent,  but  provided  the  stimulus  which  enabled  the  poten¬ 
tial  users  to  characterize  their  needs  for  a  programming  lan¬ 
guage  and  to  point  out  the  factors  which  affect  their  choice  of 
language. 

This  trial  set  of  characteristics  was  widely  distributed 
by  the  Military  Departments  with  a  request  that  the  recipients 
submit  their  own  set  of  language  requirements  in  response.  Out¬ 
side  contractors,  contacted  by  the  individual  offices  that  deal 
with  them,  responded  overwhelmingly.  The  responses  were  first 
sent  to  Working  Group  representatives  of  the  individual  Depart¬ 
ments  for  coordination  within  their  departments  and  on  to  IDA. 

IDA’S  task  was  to  analyze,  interpret,  and  resolve  the  re¬ 
sponses  into  a  consistent  and  unambiguous  set  of  needed  char¬ 
acteristics.  In  mcuiy  cases,  this  Involved  direct  consultation 
with  individual  contributors.  The  result  was  an  extensive  docu¬ 
ment  which  explained  some  of  the  implications,  noted  the  trade¬ 
offs  which  were  considered,  and,  in  general,  provided  the  ra¬ 
tionale  behind  the  listed  characteristics. 

The  whole  process  was  then  repeated.  The  revised  document 
was  distributed  by  the  Services  and,  again,  many  thoughtful  and 
helpful  responses  were  received,  processed,  analysed,  and  recon¬ 
ciled  by  IDA.  A  revised  version  of  the  characteristics  was  then 
prepared.  This  set  of  requirements  involved  few  major  changes 
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In  substance,  led  to  a  contraction  In  the  number  of  needed  char¬ 
acteristics  through  consolidation  of  related  items,  concentrated 
on  clarification,  and  led  to  the  elimination  or  weakening  of 
requirements,  which,  although  desirable,  are  not  feasible  with 
existing  programming  language  technology.  At  a  session  held 
December  10-12,  1975*  the  set  of  needed  technical  characteris¬ 
tics  for  a  common  DoD  programming  language  underv;ent  several 
minor  revisions  based  on  the  official  coordinated  Inputs  of  each 
Military  Department  and  a  detailed  review  by  the  Working  Group 
and  representatives  of  several  interested  organizations  within 
the  Services.  Further  changes  are  not  anticipated.  We  hope 
the  current  set  is  neither  vague  nor  unnecessarily  limiting;  It 
represents  a  few  compromises,  but  appears  to  be  technically 
sound  and  achievable  with  existing  technology  and  Is  a  consen¬ 
sus  of  the  Military  Departments  which  Individually  approved  It 
early  In  1976. 

The  resulting  characteristics,  presented  in  Chapter  V  and 
VI  of  this  report,  are  discursive  rather  than  quantitative  be¬ 
cause  there  are  few  useful  quantitative  measures  of  software  or 
of  programming  lejiguages.  The  depth  of  discussion  varies  accor¬ 
ding  to  the  characteristic.  The  relative  merit  of  alternative 
approaches,  the  trade-offs  Involved,  and  the  rationale  for  the 
final  choice  are  given  in  greatest  detail  for  those  language 
characteristics  which  have  greatest  Impact  on  the  language  se¬ 
lection,  have  several  competing  approaches,  or  were  resolved  In 
apparent  conflict  with  conventional  wisdom. 

C.  Findings 

The  Higher  Order  Programming  Language  Working  Group  Identifieo 
78  needed  characteristics.  Major  characteristics,  listed  below, 
were  abstracted  from  that  list.  There  Is  no  significance  in  the 
order  of  presentation. 
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1.  The  common  programming  language  can  only  achieve  its 
breadth  of  application  and  flexibility  of  expression 
by  having  a  few,  general,  abstract  concepts  and  struc¬ 
tures  which  can  be  applied  In  many  combinations.  It 
should  not  be  a  conglomerate  of  many  special  features 
of  limited  application  or  of  features  with  many  special 
cases  In  their  abstract  definitions. 

2.  The  common  language  should  have  a  high  degree  o^. general¬ 
ity  and  flexibility  at  compile  time,  but  should  be 
static  at  run  time.  The  language  Itself  should  not 
require  dynamic  storage  allocation  or  the  presence  of 

an  operating  system  In  its  object  machine. 

3.  The  language  should  require  Its  users  to  specify  the 
type  of  data  and  operations,  the  range  and  precision 
of  numeric  data,  and  the  action  to  be  taken  under  each 
alternative  condition  In  Its  programs.  These  all  rep¬ 
resent  Information  that  Is  known  to  the  programmer  and 
needed  by  those  who  must  maintain  software.  These  kinds 
of  Information  can  also  be  helpful  to  the  translator 

in  producing  more  optimal  code  and  can  aid  In  testl.ig 
and  debugging  programs. 

The  language  should  require  redundant  (not  duplicate) 
specifications  In  programs  so  that  many  program  errors 
■  can  be  detected  automatically.  For  example,  both  for¬ 
mal  and  actual  parameters  should  be  (possibly  Implicitly; 
specialized  by  type  to  permit  compatibility  checking. 

A  combination  of  typed  data  and  type  Independent  prec¬ 
edence  levels  of  operators  will  ensure  that  the  struc¬ 
ture  of  expressions  can  be  verified  both  syntactically 
and  semantically. 
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5.  The  language  should  permit  definition  of  new  data  types 
and  operations,  thus  allowing  specialization  to  par¬ 
ticular  applications  without  modification  of  the  lan¬ 
guage  definit-on,  its  translator,  or  its  support  soft¬ 
ware.  Type  definitions  may  also  enable  its  use  in  un¬ 
foreseen  applications. 

6.  The  language  should  permit  its  users  to  distinguish  be¬ 
tween  the  abstract  and  concrete  representation,  of  data, 
between  the  functional  and  algorithmic  representation 
of  opei-dtlons,  and  between  the  scope  of  allocation  and 
the  scope  of  access  for  variables.  The  ability  to  sep¬ 
arate  specifications  of  these  kinds  means  that  the  logi¬ 
cal  structure  and  intent  of  programs  need  not  be  ob¬ 
scured  by  those  aspects  which  are  concerned  only  with 
adherence  to  physical  constraints  of  the  underlying  ma¬ 
chine. 

7.  The  language  Itself  should  not  be  optimized  to  any  par¬ 
ticular  criterion,  such  as  object  code  speed,  object 
code  size,  ease  of  program  modification,  program  clar¬ 
ity,  or  ease  of  programming,  but  should  provide  facilities 
which  permit  individual  programs  to  be  optimized  to  any 

of  these  criteria.  Optimization  criteria  are  often 
application-  or  task-dependent. 

8.  The  language  should  provide  special  facilities  to  sim¬ 
plify  the  description  and  implementation  of  programs 
with  real-time  constraints  and  real-tirr.e  Interaction 
with  multiple  peripheral  devices. 

9.  The  language  should  have  a  complete  and  unambiguous  defi¬ 
nition  and  should  not  be  dependent  on  any  particular  ob¬ 
ject  machine  or  operating  system  structure. 
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10.  The  common  language  should  be  composed  of  existing  lan¬ 
guage  features,  but  may  not  be  exactly  any  existing 
language  well  known  to  m-^st  potential  users.  Thus  far, 
no  combination  of  the  needed  characteristics  which  is 
not  achievable  with  existing  programming  language  tech¬ 
nology  has  been  found  and,  if  any  were,  they  would  be 
Interpreted  as  cause  for  reducing  the  needed  character¬ 
istics.  On  the  other  hand,  since  no  identified  language 
satisfies  all  the  needed  characteristics,  some  modifica¬ 
tion  of  existing  languages  will  be  necessary.  Further¬ 
more,  regardless  of  the  language  selected,  the  diversity 
of  languages  currently  used  guarantees  that  it  will  be 
new  to  most  of  its  potential  users.  The  characteristics 
dictate  a  language  which  draws  its  features  in  obvious 
ways  from  existing  languages  and  which  avoids  many 
specific  recognized  deficiencies  of  currently  used 
languages . 

11.  A  major  emphasis  should  be  on  the  support  supplied  with 
the  language.  Ultimately,  the  success  of  the  common 
language  effort  will  depend  on  the  acceptance  of  the 
language  by  DoD  software  developers  and,  to  a  large 
extent,  that  will  depend  cn  the  availability  and  acces¬ 
sibility  of  supported  compilers,  software  aids,  and 
libraries  for  the  language. 

From  preliminary  analysis,  the  identified  needed  technical 
characteristics  for  the  Common  Higher  Order  Programming  Language 
for  military  applications  appear  to  be  self-consistent,  to  con¬ 
form  to  the  established  language  design/selection  criteria,  to 
be  acceptable  to  the  Military  Departments,  and  to  be  achievable 
wltn  existing  software  and  progra.nraing  language  technology.  More 
analysis  is  required,  however,  particularly  on  the  feasibility 
of  achieving  all  the  technical  requirements  simultaneously. 


Detailed  examination  of  existing  language  features,  language 
design  techniques,  and  compiler  implementation  and  optimization 
methods  are  needed. 

The  process  of  identifying  the  needed  technical  character¬ 
istics  for  a  Common  Higher  Order  programming  language  also  un¬ 
covered  several  possible  properties  of  the  programming  environment 
translators,  and  management  of  the  language  which  the  Working 
Group  thought  will  be  Important  to  the  success  of  the  common- 
language  effort.  These  properties  include  the  availability  of 
language-associated  software  development  tools,  standard  libraries 
translator  options,  and  source  language  diagnostics.  They  pro¬ 
hibit  superset  and  subset  implementations,  recommended  multiple- 
object-machine  translators,  and  require  self-implementation  of 
the  language.  Most  importantly,  they  require  user  documentation, 
configuration  management,  standards,  control,  and  support  for 
both  the  language  and  its  libraries. 
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I.  INTRODUCTION 

This  paper  is  concerned  with  criteria  and  issues  that  will 
have  an  impact  on  the  needed  technical  characteristics  for  a 
Common  Higher  Order  Programming  Language  for  military  applications. 

Chapter  I  gives  an  Introduction  to  the  software  and  pro¬ 
gramming  language  problems  in  DoD,  the  purpose  of  the  common 
language  effort,  and  some  related  issues. 

Chapter  II  presents  some  conflicts  that  arise  in  any  lan¬ 
guage  design  or  selection  process  and  describes  their  resolu¬ 
tion  for  the  common-language  effort. 

Chapter  III  reviews  some  of  the  major  problems  affecting 
software  design,  development,  maintenance,  and  use  in  the  DoD. 

Chapter  IV  presents  the  language  design  criteria  which 
helped  determine  the  needed  characteristics.  These  criteria 
fall  into  three  major  categories:  those  which  satisfy  spec¬ 
ialized  application  requlrem.ents ,  those  which  address  recog¬ 
nized  existing  software  problems,  and  those  which  are  intended 
to  assure  that  the  resulting  language  can  serve  as  a  common 
language . 

Chapter  V  gives  the  needed  technical  characteristics  for 
the  common  language,  while  Chapter  VI  provides  additional  re¬ 
quirements  related  to  the  programming  environment  of  the  re¬ 
sulting  language,  to  its  translators,  and  to  a  number  of  man¬ 
agement  Issues  concerning  its  definition,  standards,  support, 
and  control.  Many  of  these  Issues  will  have  direct  or  indi¬ 
rect  effects  on  the  technical  acceptability  of  candidate  lang¬ 
uages. 
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A.  THE  PROBLEM 


Ae  long  as  there  were  no  machines ,  pro¬ 
gramming  was  no  problem  at  all;  when  we 
had  a  few  weak  computers ,  programming  be¬ 
came  a  mild  problem  and  now  that  we  have 
gigantic  computers t  programming  has  become 
an  equally  gigantic  problem.  In  this  sense 
the  electronic  industry  has  net  solved  a 
single  problem,  it  has  only  created  them-- 
it  has  created  the  problem  of  using  its 
products .  > 

E,  W,  Digkstra  in  1972  Turing 
Award  Lecture 

The  past  25  years  of  digital  computer  hardware  history 
are  characterized  by  orders-of-magnitude  Increases  In  compu¬ 
ting  speed,  memory  capacity,  and  reliability.  At  the  same 
time,  the  physical  size,  power  consumption,  and  cost  of  com¬ 
puter  hardware  have  decreased  by  several  orders  of  magnitude. 
These  trends  have  led  to  inflated  expectations  and  expanded 
use  of  digital  computers  not  only  to  automate  tasks  that  pre¬ 
viously  had  been  performed  manually,  but  tasks  not  seriously 
considered  heretofore. 

The  burden  of  increased  expectations  for  computer  system.s 
has  fallen  on  software.  Software  is  the  collection  of  com¬ 
puter  programs  which  give  direction  to  the  computer  hardware, 
tailor  the  computer  to  serve  the  needs  of  the  application,  and 
specify  the  sequencing  of  individual  actions  to  be  taken  by 
the  computer  under  prescribed  conditions.  Demands  on  the  de¬ 
sign,  development,  and  maintenance  of  computer  software  are 
magnified  by  increases  in  the  speed,  capacity,  and  reliability 
of  computer  hardware. 

1 .  Software  Costs 

Although  little  reliable  information  on  the  costs  of  soft¬ 
ware  in  the  Department  of  Defense  (DoD)  is  available  in  a 
clearly  identifiable  form,  some  reasonable  estimates  have  been 
reported  (Ref.  2).  Total  annual  expenditures  for  system,  anal¬ 
ysis,  design  and  programming  of  software  in  DoD  are  estimated 
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at  $3  to  $3.5  billion,  divided  among  the  Military  Departments 
as  follows;  Army  23  percent.  Navy  36  percent,  Air  Force  36 
percent,  and  other  DoD  agencies  5  percent.  Another  study 
(Ref.  1)  has  provided  some  estimates  of  the  software  costs  by 
application,  as  shown  below.  If  management  and  logistic  in¬ 
formation  systems  are  taken  as  primarily  data  processing,  and 
if  aircraft  and  missile  engineering  and  production  are  taken 
as  primarily  scientific  programming,  then  the  remainder,  called 
embedded  computer  systems,  constitutes  55  to  75  percent  of  the 
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The  process  of  design,  implementation,  test,  documentation, 
and  maintenance  of  software  can  generally  be  called  programming. 
Programming  activity  is  constrained  by  the  availability  of  dol¬ 
lars,  real  time,  machine  resources,  competent  programming  per¬ 
sonnel,  and  programming  tools.  As  with  any  activity  in  which 
expectations  exceed  the  available  capability,  something  must 
give.  In  this  case,  the  symptons  appear  in  the  form  of  soft¬ 
ware  which  is  nonresponsive  to  user  needs,  unreliable,  inflex¬ 
ible,  difficult  to  maintain,  and  not  reusable.  The  solution 
to  the  software  problem  will  be  complex,  involving  more  and 
better  requirements  validation,  software  design  techniques, 
design  analysis,  management  visibility,  discipline  in  software 
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development,  program  validation  and  testing  methods,  mainte¬ 
nance  documentation,  education  of  programming  personnel,  and 
software  tools.  Because  there  are  so  many  aspects  to  the  soft¬ 
ware  problem  and  its  solution,  improvements  in  one  area  are 
often  difficult  to  measure  and  have  only  indirect  impact  on 
the  total  problem. 

2 .  Programming  Language 

The  programming  language  is  the  one  software  tool  which 
pervades  all  software  activity  from  design  and  development 
through  maintenance.  It  is  a  formal  rotational  mechanism  with 
which  the  programmer  specifies  desired  computation.  The  pro¬ 
gramming  language  provides  the  set  of  software  building  blocks 
in  the  form  of  variables,  data  structures,  operations,  and  con¬ 
trol  structures.  With  it,  the  program.mer  can 

•  Design,  build,  and  refine  his  programs. 

•  Obtain  the  feedback  enabling  him  to  test,  verify,  and 
debug  his  programs. 

•  Assemble  and  manage  the  component  parts  of  a  software 
system. 

Together  with  its  programs,  che  programjnlng  language  pro¬ 
vides  the  only  complete  and  accurate  documentation  of  the  soft¬ 
ware.  It  is.  Itself,  a  computer  program  in  the  form  of  a  trans¬ 
lator  converting  programs  of  the  language  into  strings  of  sym¬ 
bols  that  can  be  directly  interpreted  by  som.e  object  machine. 

It  defines  an  abstract  machine  which  associates  an  interpreta¬ 
tion  with  each  program  of  the  language,  independent  of  any 
hardware,  and  it  is  a  language  foi  communicating  procedures, 
techniques,  and  algorithms  among  software  personnel. 

3.  Lack  of  Commonality 

There  are  a  number  of  widely  held  perceptions  about  the 
ill  effects  of  the  lack  of  programming  language  commonality  in 
the  DoD.  Although  these  can  be  substantiated  only  by  examples. 
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and  their  true  extent  Is  unknown,  they  have  provided  much  of 
the  incentive  and  generated  much  of  the  initiative  for  the  com¬ 
mon-language  effort.  The  lack  of  programming  language  common¬ 
ality  in  DoD  embedded  computer  applications  may: 

•  Require  duplication  in  training  ana  maintenance  for  the 
language,  its  translators,  the  associated  software  sup¬ 
port  packages,  and  all  the  common  functions  needed  to 
use  any  language  effectively.  Programming  languages  are 
themselves  Implemented  as  computer  programs  whi,';h  must  be 
designed,  developed,  and  maintained.  The  cost  and  ef¬ 
fort  required  for  implementation,  maintenance,  and  train¬ 
ing  Increases  with  the  number  of  languages  in  active 
use. 

•  Minimize  communications  among  software  practitioners 
and  retards  technology  transfer.  The  strengths  and 
weaknesses  of  the  programming  language  affect  the  way 
one  organizes  programs,  the  techniques  employed,  and  the 
approaches  used  in  solving  computational  problems.  A 
programming  language  provides  much  of  the  technical  vo¬ 
cabulary  needed  to  communicate  about  programs  and  prob¬ 
lem-solving  methods  in  software.  Consequently,  diver¬ 
sity  in  languages  establishes  artificial  boundaries 
among  softv;are  practitioners,  complicates  communication, 
reduces  understanding  and  cooperation,  and  may  lead  to 
distrust  and  mutual  criticism.  A  prime  example  is  COBOL. 
COBOL  is  a  thoughtfully  designed  language  well  suited  to 
data  processing  applications,  where  it  is  used  almost 
exclusively.  Its  effectiveness  is  demonstrated  by  the 
stability  of  its  design  for  about  15  years.  Yet,  those 
who  have  not  used  COBOL  are  almost  universally  critical 
of  the  language.  They  know  little  about  the  language, 
except  that  it  is  different,  they  find  its  appearance 
aesthetically  displeasing,  and  are  sure  they  would  not 
like  it. 
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•  Result  In  support  software  being  project-unique  and 
tie  software  maintenance  to  the  original  developer. 
Programming  languages  are  often  developed  to  support 
individual  projects  in  DoD.  Typically,  the  language 
will  be  developed  as  part  of  the  project  effort  and  used 
only  for  that  project.  Although  the  language  is  devel¬ 
oped  at  government  expense,  the  original  software  vendor 
Is  both  its  developer  and  only  user.  This  tends  to  tie 
maintenance  of  the  application  software  to  that  vendor. 
Thus,  a  language  can  be  seen  as  a  handy  device  to  as¬ 
sure  a  continued  flow  of  business  to  the  contractor  over 
the  life  of  a  system.  This  tendency  is  strengthened  in 
the  usual  situation  in  which  the  translator  and  support 
tools  for  the  language  are  written  in  ano 'her  language 
which  is  proprietary  to  the  vendor. 

•  Diffuse  expenditures  for  support  and  maintei''ance  soft¬ 
ware  so  only  the  most  primitive  software  aids  are  devel¬ 
oped,  but  repeatedly.  Software  tools  and  aids  !.•'  the 
form  of  compilers,  interpreters,  diagnostic  aids,  de¬ 
bugging  packages,  code  optimizers,  automatic  testing 
systems,  program  editing  systems,  and  many  more  are  pro- 
gramming-language-dependent ,  and,  consequently,  must  be 
developed  for  each  new  language.  Projects  are,  of  ne¬ 
cessity,  application  oriented;  their  primary  goal  must 
be  to  develop  the  application  software.  Project  per¬ 
sonnel  have  neither  the  inclination,  time,  funds,  nor 
expertise  to  develop  more  powerful  or  more  generally 
useful  software  tools. 

•  Limit  the  applicability  of  new  support  software.  Even 
if  a  variety  of  useful  tools  were  developed  for  some 
language,  the  benefits  would  be  limited  to  the  users  of 
that  language.  Ideally,  generally  useful  software  tools 
should  be  independently  developed  and  maintained  and  made 
available  to  any  project,  but  the  diversity  of  language 
guarantees  that  any  such  independent  development  will  have 
only  limited  payoff. 


22 


•  Create  a  situation  In  which  the  adoption  of  an  existing 
language  by  a  new  project  Is  often  more  risky  and  less 
cost-effective  (at  least  during  development)  than  devel¬ 
oping  a  new  specialized  language.  There  must  always  be 
a  trade-off  between  a  specialized  language  tailored  to 
the  application  and  a  more  general  language  whose  sup¬ 
port  and  maintenance  costs  can  be  shared  across  many 
projects.  As  long  as  there  is  no  common,  widely  used 
programming  language  for  embedded  computer  applications 
which  has  useful,  independently  developed  and  maintained 
off-the-shelf  support  tools,  there  is  little  advantage 
to  selecting  an  existing  language  for  a  new  project. 
Developing  a  new  language  will  not  be  significantly 
more  expensive  than  developing  a  new  compiler  for  an  ex¬ 
isting  language  and  may  avoid  unnecessary  generality 
while  providing  features  especially  well-suited  to  the 
application. 

4 .  Common  Language 

The  Intent  of  the  coraraon  language  effort  is  to  identify  a 
language  for  DoD  which  will  eventually  supplant  all  languages  in 
military  applications  for  which  there  is  currently  no  common  lan¬ 
guage.  These  include  weapon  systems,  command  and  control,  test 
equipment,  communications,  avionics,  training,  systems  programming, 
and  embedded  computer  system  support  software.  There  is  no  in¬ 
tent  to  supplamt  COBOL  for  data  processing  applications  or  FOR¬ 
TRAN  for  scientific  applications.  Because  weapon  systems  and 
command  and  control  applications  include  both  data  processing 
and  numeric  processing  functions,  however,  the  resulting  com¬ 
mon  language  should  be  suited  to  those  applications. 

In  several  ways,  COBOL  is  a  model  for  the  common  language 
effort.  It  may  not  be  a  viable  candidate  as  a  common  language 
for  embedded  computer  systems  because  it  represents  the  soft¬ 
ware  technology  and  programming  practice  of  15  years  ago.  it 
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was  designed  specifically  for  data  processing,  and  it  lacks 
many  of  the  special  capabilities  needed  in  embedded  computer 
systems  software.  Nevertheless,  the  adoption  of  standards 
early  in  its  development,  the  consistency  of  design  throughout 
the  language,  the  early  Involvement  and  support  by  Industry, 
the  uniformity  of  its  implementations,  the  stability  of  its  de¬ 
sign,  and  its  concern  for  potential  users  are  all  characteris¬ 
tics  worth  emulating. 

? 

Another  successful  example  of  language  commonality  i5' 
CORAL-66.  In  1970,  the  United  Kingdom  Ministry  of  Defence 
formally  adopted  CORAL-66  as  the  standard  programming  language 
for  real-time  systems.  The  official  policy  disseminated  to 
Industi-y  Included  a  requirement  that  all  computers  used  in 
weapon  systems  must  have  a  tested  and  approved  CORAL-66  com¬ 
piler.  The  result  has  been  not  only  language  commonality 
within  the  United  Kingdom  military  establishment,  but  wld:-  ac¬ 
ceptance  in  the  commercial  sector  as  well. 

5.  Morse  Code  Experiment 

There  are  few  useful  measures  of  quality,  performance,  or 
cost.  There  is  insufficient  data  to  determine  quantitatively  the 
current  situation  in  software,  let  alone  predict  the  effects  of 
greater  software  commonality.  A  recent  experiment,  however, 
contributes  to  the  optimism  for  better  software  when  existing 
software  tools  are  more  widely  accessible. 

There  have  been  claims  from  the  research  community  that 
the  combination  of  powerful  and  stable  software  tools  (includ¬ 
ing  language),  proper  methodology,  and  competent  personnel  can 
improve  the  cost  and  performance  of  software  by  orders  of  mag¬ 
nitude  for  large  complex  problems.  The  Defense  Advanced  Pro¬ 
jects  Research  Agency  (DARPA)  recently  funded  an  experiment  to 
test  some  of  these  claims.  Researchers  at  MIT  were  asked  to 
build  a  software  system  to  solve  a  I’eal,  nontrivial,  ill-defined 
problem  in  an  application  with  which  they  were  unfamiliar  but 


using  tools  and  methodologies  they  had  developed  earlier  under 
DARPA  sponsorship. 

The  problem  was  to  implement  a  system  that  could  recognize 
Morse  code  generated  by  a  human  operator  in  the  presence  of 
transmission  noise.  The  product  was  impressive  in  its  ability 
to  recognize  Morse  code,  but  was  able  only  to  operate  at  one~ 
half  to  one-third  real  time.  When  this  deficiency  was  pointed 
out,  the  MIT  researchers  undertook  a  two-week  effort  which  im¬ 
proved  response  by  a  factor  of  30  to  50.  The  major  claim  made 
of  their  approach  is  the  ease  of  making  changes,  whether  for 
correctness,  to  meet  new  requirements,  c'*  to  improve  perfor¬ 
mance  . 

A  rule  of  thumb  used  in  software  development  says  that  a 
programmer  will  produce  an  average  of  ten  debugged  instructions 
per  day.  The  Morse  code  project  took  a  grand  total  of  5^  man- 
months.  The  final  system  consisted  of  object  programs,  object 
program  tables,  and  run-time  support  software  which  was  devel¬ 
oped  Independently  of  the  project.  There  were  also  a  number 
of  object  programs  developed  and  later  discarded.  Some  Morse 
code  support  software  was  developed  to  help  Implement  the  sys¬ 
tem  but  was  not  a  part  of  the  final  system.  Depending  on  which 
subsystems  are  Included  in  the  instruction  count,  the  instruc¬ 
tions  per  man-day  range  from  139  to  909-  The  results  are  de¬ 
tailed  in  Table  1.  The  figure  of  625  instructions  per  man-day 
is  most  consistent  with  usual  practice  and  the  figure  of  *191 
is  probably  the  most  fair.  The  RAND  CCIP-85  Study  (Ref.  1) 
pointed  out  that  an  Increase  of  from  10  to  11  instructions  per 
day  would,  in  theory,  save  the  Air  Force  $100  million  per  year. 
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Table  1.  Results  of  Morse  Code  Experiment 


NO.  OF  INSTRUC-  INSTRUCTIONS 

im? -  PETMATfrUAV" 


Excluding 

Program  Including  Excluding  Including 

Tables  Tables  Tables  Tables 


Object  Program 

Only 

158,000 

478,000 

139 

422 

Total  Codes 

Wri tten 

559,000 

879,000 

493 

775 

Total  Codes  in 

Final  System 
or  its  Support 

389,000 

709,000 

343 

625 

Total  Codes  Writ¬ 
ten  and  Not  Dis¬ 
carded 

237,000 

557,000 

209 

491 

Total  Codes  in 

Final  System 

210,000 

530,000 

185 

467 

Total  Codes  Written, 

71 1  ,000 

1 ,031 ,000 

627 

909 

in  Final  System,  or 
in  its  Support 
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B.  PURPOSE  OF  THE  COMMON  PROGRAMMING  LANGUAGE  EFFORT 

And  the  Lord  aaidy  Behold^  the  people  io  one, 
and  they  have  all  one  language ;  and  this  they 
begin  to  do:  and  now  nothing  will  be  restrained 
from  them,  which  they  have  imagined  to  do. 

— Genesis  XI  6 

The  purpose  of  the  Common  Programming  Language  effort  is 
to  achieve  maximum  useful  software  commonality  in  DoD  embedded 
computer  applications  through  a  reduction  in  the  number^'of 
programming  languages  used. 

Reducing  the  number  of  programming  languages  may  be  a 
slow  and  tedious  process,  since  languages  used  In  existing 
systems  can  be  phased  out  only  as  the  systems  become  obsolete 
or  go  through  major  upgrades.  Incentives  in  the  form  of  sup¬ 
ported,  easily  accessible,  and  easily  used  software  tools  and 
aids  are  needed  for  the  languages  which  remain.  The  standards 
and  stability  in  the  remaining  languages  should  not  impede  the 
use  of  new  software  tools  and  methods,  hinder  the  adoption  of 
new  programming  techniques,  or  stifle  innovation.  When  new 
languages  are  Introduced,  and  they  must  be  to  take  advantage 
of  new  software  and  programming  language  technology,  it  should 
be  done  in  a  controlled  manner  and  only  when  there  is  expecta¬ 
tion  of  major  benefits  and  full  understanding  of  the  trade-offs. 

Software  commonality  refers  to  the  reuse  of  computer  pro¬ 
grams,  software  subsystems,  or  methodologies,  either  directly 
or  after  minor  modification.  The  value  of  software  commonality 
derives  not  only  from  reduction  in  redundant  software  develop¬ 
ment,  but  from  lower  costs  for  training  and  maintenance  of  the 
resulting  systems,  more  timely  system  development,  lower  risk 
in  software  design  and  development,  and  better  communication 
among  software  practitioners. 
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The  benefits  of  reusable  software  are  greatest  for  support 
software,  including  compilers,  verifiers,  programming  and  de¬ 
bugging  systems,  and  optimizers.  Support  tools  are  often  in¬ 
effective,  because  they  are  reinvented  and  rebuilt  for  each  new 
project.  There  is  seldom  the  time  or  money  to  perfect  the  sup¬ 
port  tools  or  to  provide  any  but  the  most  primitive  capabili¬ 
ties.  If  the  same  software  is  widely  used,  costs  can  be  shared 
over  many  projects  and  each  effort  can  build  on  its  predeces¬ 
sors. 

1 .  A  Common  Programming  Language 

Software  commonality  can  be  achieved  only  through  the 
adoption  of  a  common  programming  language.  ITie  programming 
language  is  central  to  the  development  of  software.  The  soft¬ 
ware  tools  and  aids  are  built  around  specific  programming  lang¬ 
uages.  The  compilers  and  other  software  tools  are  themselves 
the  most  widely  used  computer  programs  and,  as  such,  can  espe¬ 
cially  profit  from  the  attendant  improvements  in  reusability, 
training,  maintenance,  timeliness,  risk,  and  communication. 

The  fewer  the  programming  languages  the  greater  the  lev¬ 
erage  associated  with  those  that  remain.  The  common-language 
effort  has  as  a  goal  minimization  of  the  number  of  programming 
languages  In  DoD.  The  common  language  is  Intended  to  be  a  sin¬ 
gle  or  minimal  set,  of  general-purpose  programming  language  that 
will  eventually  replace  the  many  hundreds  of  general-purpose  lan¬ 
guages  being  used  currently  in  the  DoD.  The  assumption  that  a 
single  general-purpose  language  will  suffice  must  remain  until 
specific  needs  or  conflicting  language  requirements  demonstrate 
a  need  for  more  than  one.  Neither  should  general-purpose  langu¬ 
ages  be  confused  with  application  packages,  which  are  sometimes 
called,  "application-oriented  languages".  Unlike  general-pur¬ 
pose  languages,  application-oriented  languages  can  be  used  to 
describe  computations  only  in  limited  application  areas,  are 
designed  for  use  by  practitioners  in  the  application  and  not 
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by  computer  programmers,  are  usually  interactive,  and  are  often 
nonprocedural.  The  adoption  of  a  common  programming  language 
should  lead  to  the  implementation  and  support  for  standard  ap¬ 
plication  packages.  Finally,  although  a  single,  general-purpose 
language  is  desired,  there  is  no  intent  to  impose  another  lan¬ 
guage  where  useful  language  commonality  already  exists  {e.g., 
among  COBOL  users  and  in  scientific  uses  of  FORTRAN).  Neither 
is  it  feasible  to  rewrite  existing  programs,  regardless  of  the 
merits  of  a  standard  language. 

Although  adoption  of  a  common  programming  language  is  nec¬ 
essary  to  obtain  the  benefits  of  software  commonality,  it  is 
not  sufficient.  There  have  been  many  past  efforts  which  merely 
attempted  to  standaralse  on  a  language's  syntax  ancj  semantics 
while  ignoring  performance  properties  and  program  development 
aids.  There  must  be  commonality  among  language-related  support 
tools,  commonality  in  compiler  performance,  and  support  and 
maintenance  for  the  language,  for  its  software  development  and 
maintenance  aids,  and  for  its  library  of  application  routines. 

2 .  High-Order  vs.  Low-Level  Programming  Language 

The  distinction  between  high-order  and  low-level  languages 
is  similar  to  that  between  people  and  machines.  Any  programming 
language  should  present  an  analog  to  the  underlying  machine  in 
a  form  more  amenable  to  human  use.  Low-level  languages  are  ma¬ 
chine-oriented  and  simplify  the  translation  process  at  the  ex¬ 
pense  of  human  resources.  The  higher  the  level  of  the  language 
the  more  it  caters  to  the  needs  of  the  programmer,  the  greater 
the  portion  of  software  development  which  is  automated,  and  the 
less  visible  are  the  underlying  machine  resources.  Programming 
here,  of  course,  encompasses  not  Just  coding,  but  the  entire 
spectrum  of  software  design,  development,  and  maintenance. 
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In  commenting  on  section  V.J.  of  this  report,  E.  W. 
Dljkstra  said: 

I  can  enlarge  on  that:  in  the  past,  when  we 
used  'low-level  language'  it  was  considered 
to  be  the  purpose  of  our  prograws  to  instruct 
our  machines i  now,  when  using  'high-order 
language',  we  would  like  to  regard  it  as  the 
purpose  of  our  machines  to  execute  our  pro¬ 
grams.  Run  time  efficiency  can  be  viewed  as 
a  mismatch  between  the  program  as  stated  and 
the  machinery  executing  it.  The  difference 
between  past  and  present  is  that,  in  the  past, 
the  programmer  was  always  blamed  for  such  a 
mismatch :  he  should  have  written  a  more 

efficient,  more  'cunning '  program!  With  the 
programming  discipline  acquiring  some  matur¬ 
ity,  with  a  better  understanding  of  what  it 
means  to  write  a  program  so  that  the  belief 
in  its  correctness  can  be  justified ,  we  tend 
to  accept  such  a  program  as  'a  ^ood  program' 
if  matching  hardware  is  thinkable ,  and  if, 
with  respect  to  a  given  machine,  the  afor- 
mentioned  mismatch  then  occurs,  we  now  tend 
to  blame  that  computer  as  ill-designed,  in¬ 
adequate,  and  unsuitable  for  proper  usage. 

In  such  a  situation,  there  are  only  a  few 
ways  out  of  the  dilemma:  (1)  accept  the 
mismatch,  (2)  continue  bit  pushing  in  the 
old  way,  with  all  the  known  ill-effects, 
and  (3)  reject  the  hardware,  because  it  has 
been  identi fied  as  inadequate . 

A  higher-order  language  permits  automation  of  the  more 
repetitive  aspects  of  software  development  in  return  for 
greater  constraints  on  the  programmer.  The  high-level  lang¬ 
uage  programmer  is  deprived  of  dangerous  capabilities,  such 
as  being  able  to  create  self-modifying  programs,  to  do  arith¬ 
metic  on  machine  addresses,  and  to  use  fixed-point  operations 
on  floating-point  numbers.  In  return,  the  programmer  is  able 
to  partition  his  program  into  logically  meaningful  parts,  is 
guaranteed  that  updating  one  variable  will  not  affect  others, 
and  is  given  warning  when  he  violates  his  own  assumptions  and 
stated  conditions. 
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The  costs  in  machine  resources  which  must  be  paid  for 
greater  automation  of  software  development  through  the  use  of 
high-order  programming  languages  can  be  paid  at  compile  time 
{i.e.f  the  time  of  translation)  or  at  run  time  (t.e.,  the  time 
the  software  is  used).  Many  of  the  widely  used  HOLs  simplify 
the  programming  task  by  providing  general-purpose  mechanisms 
and  many  automatic  defaults  so  that  the  programmer  not  only 
has  the  advantage  of  intuitively  meaningful  structures  and 
notations,  but  is  relieved  of  having  to  specify  his  intentions, 
assumptions,  and  the  detailed  constraints  on  his  programming 
problem.  Consequently,  information  available  to  the  program¬ 
mer  is  hidden  from  the  compiler  and  maintenance  personnel  and 
must  be  derived  dynamically  from  the  program  at  run  time,  thus 
imposing  much  greater  run  time  costs  than  would  be  associated 
with  a  corresponding  program  written  in  machine  language. 

There  are  several  ways  out  of  this  dilemma.  For  program.s 
which  are  to  be  executed  only  a  few  tlm.es  or  for  other  reasons 
have  unimportant  run  time  costs,  the  solution  has  been  to  admit 
to  the  greater  run  time  costs,  incorporate  the  run  time  environ¬ 
ment  into  the  translator  to  form  an  interpreter,  and  take  full 
advantage  of  the  machine-independent  high-order  language.  Where 
run  time  costs  are  important,  at  least  four  approaches  have  been 
tried.  The  most  widely  used  approach  in  DoD  has  been  to  allow 
portions  of  the  HOL  program  to  be  written  in  machine  language. 
This  permits  the  programmer  to  optimize  his  program.s  to  any  de¬ 
gree  within  his  capability  but  defeats  the  purpose  of  the  HOL. 
Another  approach  used  in  DoD,  but  most  popular  in  the  commer¬ 
cial  and  scientific  world,  has  been  the  optimizing  compiler. 
Large,  sophisticated  compilers  have  been  built  to  rework  the 
object  code  to  produce  an  optim.al  run  tlmie  program.  Although 
these  systems  impose  considerable  com.pile  time  costs,  they 
have  seldom  been  able  to  produce  codes  comparable  to  those  of 
good  machine  language  programmers.  The  third  approach  admits 
that  a  compiler-produced  code  is  not  as  efficient  as  handwritten 
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code  for  small  static  programs,  but  points  out  that  programs 
in  which  object  code  efficiency  is  Important  tend  to  be  large 
programs  which  are  modified  many  times.  The  mass  of  detail 
which  must  be  processed  for  effective  optimization  of  a  large 
software  package  may  be  too  much  for  even  the  best  programmer, 
and  when  success  is  achieved,  it  may  be  very  transitory  because 
assumptions  under  which  the  optimizations  were  made  change  as 
system  requirements  change. 

The  fourth  approach,  and  one  which  seems  most  reasonable 
for  the  Common  HOL  effort,  emphasizes  software  reliability, 
program  maintainability,  and  run  time  efficiency  in  the  con¬ 
text  of  the  current  programming  language  model  (e.j.,  ALGOL, 
JOVIAL,  PL/1  and  the  like).  It  gives  up  some  programming  ease 
by  using  a  language  which  requires  the  programmer  to  make  his 
assumptions  and  intentions  explicit  in  his  programs  and  which 
prevents  hiding  information  from  the  compiler  and  those  who 
maintain  the  programs.  Greater  software  reliability  results 
because  more  information  is  available  to  compiler  for  compile 
time  error  detection,  software  is  more  easily  maintained  and 
modified  because  it  is  more  readable  and  comprehensible,  and 
execution  is  more  efficient  because  more  information  is  avail¬ 
able  to  the  compiler  for  optimization  and  because  more  deci¬ 
sions  are  bound  at  compile  time-  High-level  language  programs 
should  contain  a  great  deal  of  information  of  value  to  the 
compiler  as  well  as  to  those  who  must  maintain  the  program. 

This  In  no  way  conflicts  with  the  characterization  of  the  HOL 
as  being  oriented  toward  the  programmer,  human  problem  solving, 
and  particular  application  areas  at  the  exclusion  of  machine- 
dependent  characteristics.  Programming  language  features  which 
aid  the  compiler  in  the  generation  of  efficient  object  code 
should  have  a  form  and  meaning  which  will  contribute  to  the 
understandability  of  the  program  as  well,  should  be  translator 
independent,  and,  to  the  degree  possible,  object  machine  inde¬ 
pendent  . 
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C.  OTHER  ISSUES 


There  are  a  number  of  Important  Issues  and  potential  prob¬ 
lems  associated  with  the  Common  DoD  Programing  Language  effort 
and  with  the  discovery  and  use  of  the  needed  technical  char¬ 
acteristics  for  such  a  language.  This  section  discusses  some 
of  these  Issues  and  gives  the  resolution  where  there  has  been 
a  decision  by  the  working  group. 

1 .  Scope 

The  Common  Higher  Order  Programming  Language  effort  has  been 
limited  to  embedded  computer  systems  applications  because  (1)  the 
majority  of  software  costs  in  the  DoD  are  associated  with  weap¬ 
ons  systems  applications,  (2)  COBOL  and  FORTRAN  already  satisfy 
many  of  the  commonality  goals  of  this  effort  for  data  process¬ 
ing  and  scientific  applications,  respectively,  the  two  major 
areas  which  have  not  been  included,  and  (3)  the  large  number 
of  unique,  nonstandard,  general-purpose  programming  languages 
used  in  the  DoD  are  used  in  embedded  systeais  applications. 

The  scope  of  the  effort  has  not  been  further  restricted 
within  embedded  systems  applications  because  (1)  specialized 
applications  within  weapons  systems  have  similar  software  prob¬ 
lems,  (2)  embedded  systems  applications  are  not  pure  and  require 
computations  in  many  specialized  areas  within  the  same  system, 

(3)  the  technical  requirements  for  the  individual  applications 
have  proven  to  be  nearly  identical,  and  (^)  no  conflicting  re¬ 
quirements  have  been  found. 

2 .  Application-Oriented  Languages 

The  Common  Higher  Order  Programming  Language  is  Intended  to 
eventually  supplant  all  general-purpose  programming  language  used 
in  embedded  systems  applications  in  the  DoD.  It  is  not  Intended 
to  replace  application-oriented  languages.  Application-oriented 
languages  are  similar  to  programming  languages  in  that  they  en¬ 
able  their  user  to  describe  a  computation  which  will  be  carried 
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out  by  a  digital  computer.  They  are  unlike  general-purpose 
languages  in  that  they  provide  very  specialized  capabilities 
for  a  restricted  problem  domain,  they  are  intended  for  use  by 
those  familiar  with  the  application  and  usually  do  not  require 
specific  programming  knowledge,  they  are  often  nonprocedural, 
and  in  many  cases  are  accessible  interactively.  Any  applica¬ 
tion  package  is  an  example  of  an  application-specific  language. 
The  Common  Higher  Order  Programming  Language  effort  is  concerned 
with  the  general-purpose  procedural  programming  languages  used 
to  implement  applications  and  systems  software,  and  is  not  in¬ 
tended  to  replace  application-oriented  software. 

3 .  Effect  on  Software  Expenditures 

The  projected  overall  benefits  of  any  standardization 
should  exceed  its  disadvantages.  Ideally,  there  should  be  a 
complete  cost-benefit  analysis,  comparing  costs  with  and  with¬ 
out  standardization,  including  life-cycle  costs.  This  is  not 
feasible  for  software/programming  languages,  because  their  cos  s 
are  diffused  throughout  weapons  systems  procurements  and  are 
seldom  identifiable.  We  do  know,  however,  that  most  costs  are 
for  personnel,  that  there  are  hundreds  of  general-purpose 
languages  in  use  in  DoD,  that  much  software  work  is  duplicative 
because  similar  software  (particularly  system  and  support  soft¬ 
ware)  must  be  redundantly  developed  for  each  language,  and  that 
the  diversity  of  programming  language  has  com.plicated  the  de¬ 
velopment  of  widely  applicable  programming  tools  and  aids  which 
could  alleviate  or  reduce  many  of  the  recognized  software  prob¬ 
lems  . 

It  is  likely  that  adoption  of  a  Common  Programming  Langu¬ 
age  will  result  in  better  communication  among  software  practi¬ 
tioners;  easier  transfer  of  new  software  technology  to  produc¬ 
tion  systems;  greater  software  reusability;  easier  transfer  of 
personnel  among  projects;  greater  visibility  of  underlying  soft¬ 
ware  problems;  Increased  programmer  productivity;  Improved 
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software  quality;  and  development  of  better  and  more  applica¬ 
ble  software  design,  development,  and  maintenance  aids.  Re¬ 
duced  costs  might  be  expected,  not  Just  from  the  adoption  of 
a  common  lamguage,  but  from  the  prohibition  on  the  development 
of  other  new  programming  languages.  Development  costs  for  other 
new  programming  languages  will  be  eliminated  (prior  to  January 
1975,  there  were  typically  several  at  any  given  time  under  de¬ 
velopment  by  elements  within  each  Military  Department).  Com¬ 
piler  costs  will  be  reduced,  even  when  new  digital  computers 
are  introduced,  because  a  common  language  with  its  machlne-iri- 
dependent  portions  written  in  its  own  language  means  that  a 
new  computer  can  be  made  accessible  by  reimplementing  only  the 
code-generation  portion.  Because  tools,  programming  aids,  and 
other  support  software  will  be  more  widely  applicable,  the 
total  cost  of  its  development  and  maintenance  should  ^e  reduced. 
Similarly,  the  training  costs  for  a  single  widely  used  langu¬ 
age  should  be  lesf  than  those  for  the  many  project-unique  lang¬ 
uages.  Finally,  as  with  any  successful  standardization  effort, 
the  common  language  should  encourage  com.petltlon  in  software 
development  and  give  more  freedom  to  change  vendors. 

It  does  not  follow,  however,  that  total  software  expendi¬ 
tures  in  the  DoD  will  be  reduced.  Benefits  of  a  successful 
common-language  effort  must  be  limited  to  new  software  develop¬ 
ments.  A  primary  impediment  to  reliable  software  is  change  to 
existing  computer  programs.  A  common  language  might  be  used  in 
new  software  efforts,  but  it  is  seldom  economical  to  reimple¬ 
ment  existing  systems.  More  importantly,  constantly  Increasing 
personnel  costs,  more  demanding  military  system  requirements, 
and  continuing  budget  pressures  have  led  to  more  and  more  auto¬ 
mation.  Computer  software  is  a  major  component  of  electronic 
equipment  procurements,  so  any  increase  in  software  productiv¬ 
ity  or  quality  will  likely  accelerate  this  trend.  Success  in 
the  common- language  effort  may  reduce  the  cost  of  softv.-are  and 
increase  its  quality,  but  these  will  likely  be  accompanied  by 
increases  in  software  expenditures. 
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4.  Effect  on  Software  and  Programming  Language  R&D 

The  adoption  of  a  common  language  should  give  greater  vis¬ 
ibility  to  software,  should  separate  the  language  design  issues 
from  the  more  important  software  problems,  and  should  provide 
a  base  for  comparing  software  techniques.  It  ^ould  provide  a 
community  of  users  who  can  share  the  design,  development,  and 
maintenance  costs  of  more  capable  software  tools.  It  should 
provide  a  vehicle  for  transfer  of  software  tedtnology  from  re¬ 
search  and  development  to  practical  use.  It  sitould  provide  a 
bigger  market  for  individual  software  tools  (wfclch  are  often 
specific-language  oriented)  and  should,  therefore,  amplify  any 
benefits  of  the  National  Software  Works.  The  separation  of 
language  issues  from  other  problems  of  software  development  may 
serve  to  identify  language  deficiencies,  problems,  and  needs 
for  innovation  in  language  design,  and  thus  lead  to  Increased 
programming  language  research  and  development. 

All  these  effects  tend  to  give  greater  visibility  to  the 
real  underlying  software  problems  and  to  the  Importance  and 
benefits  of  their  solution.  A  com.mon  language  may  give  visi¬ 
bility  to  the  sparseness  of  current  software  research  and  de¬ 
velopment  efforts,  and  point  out  the  need  for  Improved  soft¬ 
ware  development  m.'thods,  techniques,  tools,  and  aids.  It 
will  likely  lead  to  a.;  expanded  DoD  R&D  program  in  software 
and  in  programming  languages,  but  one  directed  more  toward 
finding  practical  solutions  to  important  recognized  problems. 

5.  Direct  Costs  of  Common- Lan luaqe  Effort 

There  will  also  be  several  costs  associated  with  obtain¬ 
ing  a  common  language.  There  are  the  development  costs  for  the 
language  itself;  there  are  design,  development,  implementation, 
maintenance  costs  for  its  compilers,  support  software,  and  re¬ 
lated  programming  aids;  and  there  are  training  costs  for  its 
users.  In  each  of  these  cost  areas,  however,  the  adoption  of  a 
common  language  should  result  in  reduced  expenditures,  because 
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the  conunon  language  effort  replaces  many  similar  local  efforts 
that  would  otherwise  have  taken  place  within  the  Military  De¬ 
partments.  Even  for  a  single  large  military  system  development, 
Independent  development  of  the  programming  language,  compilers, 
6Uid  software  support  tools  will  remove  those  efforts  from  the 
application  software  development  and  thereby  reduce  the  devel¬ 
opment  time  for  the  application  software  (timeliness  is  a  ma¬ 
jor  Indirect  cost  of  software).  That  one  development  can  be 
used  by  many  projects,  of  course,  eliminates  many  redundant 
expenditures.  Finally,  without  speculating  on  the  total  cost 
of  the  common  lainguage  effort,  it  should  be  noted  that  at  a 
level  of  $3  million  per  year,  it  would  be  less  than  0.001  x 
the  annual  DoD  software  costs  and  at  $10  million  {i.e.,  approx¬ 
imately  100  man-years  per  year)  it  would  be  much  less  than  1 
percent  of  software  costs. 

6.  Standardizati on 

Standards  programs  should  not  be  undertaken  unless  cer¬ 
tain  criteria  are  met.  There  should  be  several  potential  users 
of  the  standard  (in  this  case  all  new  embedded  computer  ap¬ 
plication  in  DoD).  There  should  be  a  mature  technology  well 
In  hand  (in  this  case  the  FORTRAN,  COBOL,  ALGOL,  PL  1-like 
programming  language  technology).  There  should  be  a  potential 
market  large  enough  to  support  at  least  one  contractor  for 
several  years.  The  projected  overall  benefits  of  standardiza¬ 
tion  should  exceed  its  disadvantages  (see  previous  subsection). 
And,  adoption  of  the  standard  language  by  individual  systems 
should  not  be  a  major  problem  (in  this  case,  it  should  be  no 
worse  than  adopting  a  nonstandard  language,  and  much  easier, 
providing  the  common  language  is  widely  used  and  well-supported). 


7 .  A  New  Language 

It  Is  tiiost  desirable  that  the  selected  common  language  be 
an  existing  language,  and  If  that  Is  not  feasible,  that  It  be 
a  modification  of  an  existing  language.  Given  the  Identified 
requirements.  It  Is  likely  that  most  features  of  the  selected 
language  will  be  familiar  to  most  DoD  users,  and  that  It  will 
not  be  exactly  compatible  with  any  existing  language  Implemen¬ 
tation  In  the  DoD.  The  familiar  features  are  llk&ly  because 
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the  requirements  dictate  a  FORTRAN,  ALGOL,  PL  1-llke  language 
and  were  selected  to  be  compatible  with  existing  programming 
language  technology.  The  Incompatibilities  of  existing  imple¬ 
mentations  guarantee  that  it  will  differ  from  almost  all  im¬ 
plementations  of  languages  used  currently  In  the  DoD.  The  se¬ 
lected  language  will  be  new  to  almost  all  Its  users  because: 

•  Definitions  of  existing  languages  are  vague. 

Incomplete,  and  ambiguous,  resulting  In  creation 
of  a  new  Incompatible  dialect  with  each  Imple¬ 
mentation  . 

•  The  selected  language  Is  to  emphasize  program 
reliability  and  maintainability  o/er  programming 
ease,  the  traditional  goal. 

•  The  requirements  encompass  the  needs  of  all  em¬ 
bedded  computer  systems  applications  and  not 
Just  those  perceived  by  programmers  on  a  particu¬ 
lar  project. 

•  The  requirements  legislate  away  many  of  the  known 
deficiencies  (e.g.,  error-prone  features)  of  ex¬ 
isting  languages. 

•  The  language  will  Incorporate  many  of  the  special 
characteristics  needed  by  embedded  military  system 
applications.  These  have  been  largely  ignored  In 
the  more  commonly  used  languages  (which  were  In¬ 
tended  primarily  for  scientific  and  data  processing 
computations ) . 
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•  Any  attempt  to  standardize  on  one  precise  def¬ 
inition  of  any  existing  language  cannot  work, 
because  its  divergent  dialects  are  defined  by 
their  implementations  and  are  therefore  machine- 
dependent  . 

A  new  language  name  is  desirable.  Even  if  the  language 
is  a  precise  definition  of  some  umbrella  name  language  widely 
used  in  DoD,  it  should  be  relabeled  to  distinguish  it  from 
the  existing  divergent  dialects.  The  common  language  should 
closely  resemble  (particularly  in  semantics)  many  of  the  ex¬ 
isting  DoD  languages,  but  which  particular  one  is  modified  to 
obtain  the  selected  common  language  is  of  little  significance. 

8.  Size 

Each  of  the  characteristics  described  in  Chapter  V  ad¬ 
dresses  one  or  several  related  issues  in  the  design  of  a  pro¬ 
gramming  language.  In  several  cases,  the  issues  are  complex 
and  the  discussion  quite  involved.  This  does  not,  however, 
imply  that  the  selected  language  must  be  large  or  complex. 

Each  needed  characteristic  specifies  how  the  design/selection 
process  v/ill  resolve  some  issue  affecting  the  design,  imple¬ 
mentation,  or  use  of  the  language.  Where  possible,  they  avoid 
choices  of  particular  language  features^  Each  issue  must  ul¬ 
timately  be  resolved;  Chapter  V  provides  some  of  the  analysis 
and  rationale  where  there  is  reason  for  a  particular  resolu¬ 
tion  and  provides  guidelines  where  no  clear  resolution  is  in¬ 
dicated  by  the  application  requirements,  relevant  trade-offs, 
or  the  goals  of  the  common  language  effort.  The  number  of 
issues  is,  of  course,  almost  independent  of  the  resulting 
language  and  has  little,  if  any,  relation  to  the  number  of 
features  or  the  size  of  the  language. 
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9.  Priorities 


There  is  no  ordering  of  priorities  among  the  needed  char¬ 
acteristics,  because  (1)  the  priorities  are  typically  applica¬ 
tion  dependent  and,  therefore,  dissimilar  for  the  various  po¬ 
tential  users  in  the  DoD,  (2)  priorities  are  of  no  value  what¬ 
soever,  as  long  as  none  of  the  characteristics  are  in  conflict 
and  can  be  achieved  simultaneously,  and  (3)  the  establishment 
of  priorities  may  unnecessarily  serve,  in  effect,  to  eliminate 
the  lower-priority  requirements.  Priorities  should  be  con¬ 
sidered  only  if  and  when  compromise  becomes  necessary. 

10.  Consi stency 

It  is  very  Important  that  the  needed  characteristics  be 
achievable  in  combination  with  low-risk  technology.  Examples 
of  existing  programming  languages  which  satisfy  each  indivi¬ 
dual  needed  characteristic  are  known,  but  whether  all  can  be 
satisfied  together  remains  a  question  of  Judgment,  and  there 
are  differing  opinions.  Any  fonnal  demonstration  that  they 
are  self-consistent  is  probably  still  beyond  the  capability  of 
computer  science.  A  more  pragmatic  demonstration  is  required. 
Ultimately,  the  only  acceptable  proof  will  be  one  or  several 
programming  languages  that  satisfy  the  requirements.  If  there 
are  conflicts,  they  will  become  apparent  in  the  design/modifi¬ 
cation  process  and  must  be  resolved  at  that  point. 

1 1 .  Committee  Design 

A  set  of  needed  language  characteristics  has  been  estab¬ 
lished.  The  modification  of  an  existing  language  design  re¬ 
quires  sound  engineering  and  design  practice  by  qualified 
people  and  is  Inappropriate  to  the  compromise  process  of  com¬ 
mittees.  Consequently,  the  language  will  be  selected  from 
candidates  that  have  been  reviewed  by  persons  knowledgeable  in 
the  intended  applications,  in  the  construction  of  compilers, 
and  in  the  design  of  languages.  The  Working  Group  will  not  de¬ 
sign  or  modify  languages. 
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12.  Nontechnical  Needs 


The  success  of  the  Common  Higher  Order  Programming  Language 
effort  ultimately  will  depend  not  so  much  on  the  technical  char¬ 
acteristics  of  the  language  selected  as  on  philosophical,  manage 
ment  support,  and  procurement  Issues.  Some  general  approaches 
to  these  issues  have  been  determined  by  the  Working  Group  and 
are  reported  in  Chapter  VI. 
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II.  MAJOR  CONFLICTS  IN  CRITERIA  AND  NEEDED  CHARACTERISTICS 


Five  major  conflicts  were  Identified  in  attempting  to  find 
a  consistent  and  appropriate  set  of  criteria.  In  several  cases, 
a  closer  examination  of  what  was  actually  intended  revealed 
that  seeming  conflicts,  in  fact,  did  not  exist. 

A.  SIMPLICITY  VS.  SPECIALIZATION 

The  common  programming  language  must  be  useful  for  many 
seemingly  diverse  applications,  each  with  its  own  specialized 
needs.  Suitability  of  the  language  for  each  of  the  applica¬ 
tions  is  essential  if  it  is  to  have  wide  applicability.  This 
suggests  a  need  for  a  large  conglomerate  language  with  many 
specialized  subsets.  At  the  same  time,  the  single  most  preva¬ 
lent  sympton  of  the  software  problem  is  the  complexity  of  pro¬ 
grams  and  its  adverse  effects  on  the  timeliness,  reliability, 
responsiveness,  flexibility,  and  maintainability  of  software. 
Probably  the  greatest  contributcr  to  unnecessary  complexity 
in  programs  is  the  use  of  overly  elaborate  languages  with  large 
numbers  of  complex  features  specialized  in  the  hope  of  provid¬ 
ing  every  anticipated  application  with  capabilities  unique  to 
that  application.  The  result,  in  many  cases,  is  a  grotesque 
language,  expensive  for  everyone,  understandable  to  none,  and 
well-suited  to  few  real  problems. 

The  pi’oblem  is  how  to  satisfy  simultaneously  the  need 
for  simplicity  and  specialization  in  the  same  programming  lang¬ 
uage.  The  only  method  of  which  we  are  aware  is  to  achieve 
simplicity  through  the  use  of  a  simple,  general-purpose  language 
which  has  all  the  power  necessary  for  all  the  Intended  applica¬ 
tions,  but  has  not  yet  specialized  that  power  for  any  particular 
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application.  Such  a  language  would  have  a  few  general-purpose 
data  structures;  operations  and  control  structures,  each  pro¬ 
viding  a  single,  well-defined  capability,  and  all  composable 
to  form  more  specialized  capabilities  needed  in  particular 
applications.  The  language  should  provide  a  simple,  consis¬ 
tent,  and  easily  learned  semantic  and  syntactic  framework. 

There  should  be  definition  facilities  within  the  language  to 
permit  definition  of  new  data  and  operations,  but  only  within 
the  built-in  framev;ork,  so  basic  understanding  of  programs 
written  in  the  language  would  not  be  undermined  by  new  defini¬ 
tions  within  the  language.  Such  a  language  alone,  however, 
can  only  provide  the  simplicity  and  the  power  to  build  data 
and  operations  for  specialized  applications;  it  alone  will 
not  make  useful  definitions  available  to  the  software  practi¬ 
tioners  with  the  applications.  To  be  useful,  and  to  satisfy 
the  specialized  needs  of  the  various  applications,  there  must 
be  a  predefined,  application-oriented  library  of  definitions 
available  with  the  language.  These  application  packages  must 
have  the  same  support,  standardization,  and  control  afforded 
the  base  language.  As  definitions,  they  will  not,  however., 
add  to  the  complexity  of  other  applications,  need  not  affect 
the  implementation,  and  will  be  totally  independent  and  unable 
to  in .'.erfei’e  with  other  application  subsets. 

Neither  should  we  think  that  simplicity  and  uniformity  or 
even  power  in  language  will  make  programming  easy.  Intrinsic 
complexities  which  follow  from  the  task  will  remain.  The  pur¬ 
pose  of  a  high-order  language  is  to  remove  the  unnecessary  com¬ 
plexities  which  arise  from  weaknesses  in  the  programming  lang¬ 
uage,  operating  system,  or  underlying  conputer  hardware. 
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B.  PROGRAMMING  EASE  VS.  SAFETY  FROM  PROGRAMMING  ERRORS 


There  is  a  clear  trade-off  between  progranming  ease  and 
safety.  The  more  tolerant  the  programming  language  and  the 
less  it  requires  in  specifications  of  the  intent  and  assump¬ 
tions  of  the  programmer,  the  easier  the  coding  task.  A  lang¬ 
uage  which  does  not  require  declaration  of  variables,  permilts 
any  type  of  structure  of  data  to  be  used  anywhere  without  speci¬ 
fication,  allows  short  cryptic  identifiers,  has  large  numbers 
of  default  conventions  and  coercion  rules  to  perm, it  the  use  of 
any  operator  with  ary  operand,  and  is  capable  of  assigning 
meaning  to  most  strings  of  characters  presented  as  a  program, 
will  be  very  easy  to  use,  but  also  very  easy  to  abuse.  .Safety 
from  errors  is  enhanced  by  redundant  specifications,  by  includ¬ 
ing  not  only  what  the  program,  is  to  do,  but  what  the  author's 
intentions  and  assumptions  are.  If  everything  is  made  explicit 
in  programs  with  the  language  providing  few  defaults  and  ir.- 
pllclt  data  conversions,  then  translators  can  autom.atlcally  de¬ 
tect  not  only  syntax  errors  but  a  wide  variety  of  ser, antic  and 
logic  errors.  Considering  that  coding  is  less  than  one-sixth 
the  total  programming  effort,  and  that  there  are  major  software 
reliability  and  r.alntenance  problem.s,  this  trade-off  should  be 
resolved  in  favor  of  error  avoidance  and  against  programming 
ease . 

Resolving  this  trade-off  in  favor  of  safety  at  the  pro¬ 
gramming  language  level  is  Important  not  only  for  large,  long- 
lived  weapons  systems,  but  for  any  large  long-lived  computer 
program.,  specifically  support  software,  interactive  application 
packages,  and  software  development  and  maintenance  aids.  In 
specialized  application  software,  the  ease  with  which  the  user 
(an  application  specialist  rather  than  a  computer  specialist) 
can  Interface  with  the  application  software  is  of  primary  im¬ 
portance,  and  user  requests  are  often  small  and  short-lived. 

The  application  package  itself,  however,  will  often  be  large 
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and  long-lived,  and  thus  should  be  written  and  maintained  in 
a  language  which  favors  program  correctness  and  maintainabil¬ 
ity,  even  if  this  costs  in  terms  of  programming  ease.  The 
Common  Programming  Language  itself  need  not  be  Interactive  and 
should  not  affect  programming  ease  at  the  expense  of  other  more 
important  criteria,  but  it  should  be  possible  within  the  Com¬ 
mon  Programming  Language  to  develop  and  maintain  interactive 
application  packages  with  convenient,  easy-to-use  user  inter¬ 
faces  . 

C.  OBJECT  EFFICIENCY  VS.  PROGRAM  CLARITY  AND  CORRECTNESS 

Two  apparently  opposing  views  have  been  suggested.  One, 
that  a  sim.ple  analysis  of  either  development  or  life-cycle 
costs  shows  that  reliability,  mcdifiabillty ,  and  maintainabil¬ 
ity  are  the  m.ost  Im.portant  factors,  and,  consequently,  clarity 
and  correctness  of  programs  must  be  given  consideration  over 
efficiency  of  the  object  code,  which  only  Increases  the  cost  of 
computer  hardware  (hardware  relatively  cheap  compared  to  soft¬ 
ware).  In  fact,  if  programs  need  not  work  correctly  they  can 
easily  be  Implemented  with  zero  cost.  The  other  view  points 
out  real  problems  and  applications  within  DoD  software  in  which 
the  machine  capability  is  fixed  and  in  which  object  code  effic¬ 
iency  is  of  utmost  importance  and  must  be  given  preference  over 
other  considerations. 

These  views  are  not  inconsistent  with  regard  to  the  effect 
on  programming  language  selection.  In  the  vast  m.ajority  of 
cases,  clarity  and  correctness  are  more  important  than  object 
code  efficiency  and  the  programming  language  should  do  the  ut¬ 
most  to  aid  the  programmer  in  developing  correct  and  understand¬ 
able  programs  within  constraints  of  reasoEiable  object  efficiency. 
In  many  cases,  language  features  which  Improve  clarity  do  not 
adversely  affect  efficiency.  In  many  cases,  additional  infor¬ 
mation  supplied  to  clarify  a  program  will  permit  the  compiler  to 
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use  optimizations  not  applicable  in  more  general  cases.  There 
remain,  however,  special  situations  in  which  efficiency  is 
critical.  The  language  should  not  prohibit  access  to  machine 
features  necessary  to  accomplish  those  optimizations  when  the 
need  arises.  Thus,  the  major  criteria  in  selecting  a  program¬ 
ming  language  should  be  clarity  and  correctness  of  programs 
within  the  constraint  of  allowing  generation  of  extremely  ef¬ 
ficient  object  codes  when  necessary. 

0.  MACHINE  INDEPENDENCE  VS.  MACHINE  DEPENDENCE 

Object  machine  dependencies  occur  in  digital  computer  pro¬ 
grams  for  at  least  three  reasons.  First,  programs  are  llmiced 
by  the  choice  of  capability  and  capacity  of  the  resources  avail¬ 
able  in  the  object  machine  environment.  Programs  written  for 
machines  with  different  memory  sizes,  different  peripheral  con¬ 
figurations,  and  specialized  hardware  capabilities  cannot  be 
totally  machine-independent.  Programming  languages  can,  how¬ 
ever,  treat  these  inherent  limitations  in  a  uniform  way  by  per¬ 
mitting  their  users  to  describe  the  resources  needed  in  their 
programs  and  the  translator  producing  diagnostic  messages  when 
the  program  requirements  exceed  the  capabilities  of  the  object 
machine . 

Sometimes  machine  dependencies  occur  in  programs  v/hen  the 
same  capability  is  provided  by  different  mechanisms  in  the  var¬ 
ious  object  machines.  These  machine  dependencies  ca  i  be  avoided 
when  a  higher-order  programming  language  is  used.  When  evalua¬ 
ting  an  arithmetic  expression,  the  number  of  machine  operations, 
the  form  of  the  operations,  and  the  management  of  registers  and 
storage  are  quite  different,  depending  on  whether  the  object  ma¬ 
chine  has  a  single-address,  two-address,  three-address,  stack, 
or  general-register  architecture.  Nevertheless,  the  programming 
language  can  eliminate  these  machine  dependencies  from  source 
programs  by  providing  a  single  abstraction  of  these  mechaniza¬ 
tions  in  the  form  of  algebraic  expressions.  Similarly,  real 
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time  clocks  might  be  provided  in  the  object  machine  as  a 
single  writable  countdown  register  which  interrupts  on  under¬ 
flow,  or  as  a  pair  of  registers,  one  of  which  is  a  read-only 
counter  with  an  Interrupt  when  the  register  contents  are  iden¬ 
tical.  Although  the  mechanisms  are  different,  they  both  pro¬ 
vide  the  ability  to  cause  an  Interrupt  after  (or  at )  a  speci¬ 
fied  time.  A  single  programming  language  feature  can  make  this 
capability  available  to  the  source  language  programmer  without 
imposing  a  particular  object  representation. 

A  third  form  of  machine  dependency  occurs  in  programs  in 
which  the  programmer  knows  that  certain  language  constructs, 
operations,  or  programming  techniques  are  particularly  effic¬ 
ient  or  costly  on  his  intended  object  machine.  This  form  of 
machine  dependency  is  sometimes  necessary  and  is  unavoidable 
in  languages  which  permit  the  description  not  only  of  what  a 
program  is  to  do,  but  how  that  computation  is  to  be  accomplished. 
If  the  source  language  definition  is  complete  and  unambiguous 
and  the  translators  implement  the  source  as  defined,  then  this 
form  of  machine  dependency  will  not  adversely  affect  the  abil¬ 
ity  to  coriectly  compile  and  run  programs  on  other  than  the  in¬ 
tended  object  machine. 

A  machine-independent  language  is  one  in  which  any  of  its 
programs  can  be  compiled  and  will  run  corr'^.  vly  on  any  object 
machine  of  the  language,  provided  that  the  program  does  not 
call  for  greater  capability  or  more  resources  than  are  avail¬ 
able  on  the  particular  object  machine.  This  means  that  the 
language  must  permit  the  programmer  to  avoid  unnecessary  machine 
dependencies  in  his  programs.  It  should  permit  the  user  to  de¬ 
scribe  the  ranges,  precisions,  and  types  of  data  and  operations 
needed  in  his  programs,  rather  than  forcing  his  concern  to  the 
actual  word-sizes,  arithmetic  type,  and  internal  representations 
provided  in  the  object  machine.  The  programming  language  can 
and  should  be  independent  of  the  object  machine  characteristics 
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and  the  compiler.  At  the  same  time,  It  should  be  possible  to 
write  machine-dependent  programs  as  described  in  the  first  and 
third  paragraphs  above.  When  a  program  exceeds  the  capacity  or 
capabilities  of  the  intended  object  machine,  the  error  should 
be  reported  by  the  translator.  Even  the  111-effects  of  machine 
language  insertions  and  machine-dependent  data  representations 
Ccin  be  minimized  by  requiring  that  they  be  within  the  body  of 
a  conditional  which  is  dependent  on  the  object  machine  configu¬ 
ration. 

E.  GENERALITY  VS.  SPECIFICITY 

A  problem  which  often  arises  in  looking  at  more  detailed 
programming  language  characteristics  is  the  trade-off  between 
specialized  and  more  general  features.  General  features  can 
satisfy  a  greater  variety  of  needs  and  can  be  specialized  to 
meet  many,  possibly  unforeseen  conditions.  Specialized  capa¬ 
bilities  are  often  more  efficient  than  specialization  of  gen¬ 
eral  capabilities  and,  therefore,  less  expensive  in  use.  Both 
points  are  often  true  in  practice  but  the  latter  need  not  be. 
Generality  can  be  achieved  by  consolidating  many  diverse  cases 
into  a  single  general-purpose  structure  which  treats  each  as 
a  special  case,  or  it  can  be  achieved  by  identifying  the  prim¬ 
itive  building  blocks  from  which  more  specialized  structures 
are  built.  The  latter  approach  has  several  advantages  in  pro¬ 
gramming  languages.  First,  because  all  language  features  ul¬ 
timately  must  have  a  representation  in  terms  of  computer  hard¬ 
ware  primitives,  composable  general-purpose  programming  langu¬ 
age  primitives  which  have  a  simple  representation  in  hardware 
primitives  can  be  used  to  compose  specialized  language  struc¬ 
tures  as  efficiently  as  could  be  done  by  building  them  in. 
Secondly,  general  purpose  language  primitives  which  emulate 
single  machine  language  capabilities,  but  at  the  user  level, 
will  obligate  the  user  to  pay  only  for  the  capabilities  he  needs 


49 


The  trouble  with  specialized  capabilities  built  into  a  pro¬ 
gramming  language  is  that  they  seldom  are  specialized  in  pre¬ 
cisely  the  direction  needed  for  the  problem  at  hand.  The 
ALGOL-60  for  statement  is  extremely  useful  and  desirable  if 
one’s  loop  requires  a  control  variable,  has  a  sequence  of  possi¬ 
ble  terminal  conditions  affecting  different  iterations,  and 
needs  to  be  able  to  change  the  terminal  value  of  the  index  vari¬ 
able  from  within  the  loop  body.  Seldom  are  all  these  aapabll- 
ities  needed,  but  all  must  be  paid  for  in  program  clarity, 
language  complexity,  and  object  efficiency.  A  programming 
language  should  strive  to  provide  a  base  of  simple,  single¬ 
purpose,  composable  primitives  and  leave  the  specialization  to 
supported  application  packages  and  to  user  programs.  The  lang¬ 
uage  primitives  should  be  machine-independent  abstractions  of 
machine  primitives  which  have  an  obvious  and  efficient  repre¬ 
sentation  in  most  machines. 

Care  must  be  exercised  to  Insure  that  language  structures 
which  are  defined  within  a  language,  instead  of  being  built  in, 
can  be  implemented  efficiently.  If  the  notatlonal  mechanism 
used  to  make  a  definition  requires  over-specifications  which 
are  not  necessary  to  the  Intended  structure,  then  the  compiler 
has  no  way  of  knowing  that  these  additional  specifications  are 
unnecessary  and  it  must  provide  for  them.  Although  it  is  not 
currently  possible  to  write  programs  in  an  abstract  language 
which  specifies  only  the  essential  aspects  of  defined  struc¬ 
tures  and  then  to  use  a  compiler  which  will  find  an  optimal 
concrete  representation  from  that  description,  it  is  possible 
to  separate  the  abstract  and  concrete  descriptions  of  defined 
features  so  that  the  idiosyncrasies  and  special  characteristics 
of  a  particular  implementation  do  not  interfere  with  the  clear 
understanding  and  easy  use  of  th  defined  feature. 
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III. 


THE  MOST  PRESSING  SOFTWARE  PROBLEMS* 


The  problems  mentioned  below  are  derived  from  a  variety 
of  in-house  and  contractor  studies  of  the  software  problem  in 
DoD  as  well  as  the  Service  inputs  to  the  common-language  ef¬ 
fort.  It  should  be  noted,  however,  that  these  problems  are 
unique  neither  to  the  military  nor  to  software. 

The  cost  of  software  is  high  and,  therefore,  its  problems 
are  worth  examining  in  more  detail.  Software  costs  in  the  DoD 
are  estimated  at  $3  to  $3.5  billion  annually.  Another  $2  to 
$3  billion  is  consumed  in  the  support  and  operation  of  digital 
computer  systems.  These  compare  with  computer  hardware  pro¬ 
curement  and  maintenance  costs  estimated  at  $1  to  $1.5  billion 
per  year.  Approximately  70  percent  of  all  computer  costs  (t.e., 
computer  hardware,  software,  and  operations)  are  for  personnel. 
Essentially  all  software  costs  are  for  system  design,  analysis, 
and  programming  personnel.  Of  these,  75  percent  represent  in- 
house  costs. 

That  software  costs  are  high  does  not  necessarily  mean 
that  they  are  excessive.  In  some  cases,  computers  are  used  to 
automate  previously  manual  tasks.  With  rapidly  rising  person¬ 
nel  costs,  declining  computer  hardware  costs,  amd  stable  or 
declining  software  costs  (for  given  tasks),  it  is  likely  in 
such  cases  that  total  costs  have  been  reduced  through  the  use 
of  computers.  In  many  more  cases,  the  use  of  computers  pro¬ 
vides  increased  capabilities  for  tasks  in  which  people  are  too 
slow,  inaccurate,  or  otherwise  ill-suited.  It  is  difficult  to 
place  dollar  values  on  improved  or  Increased  capabilities. 

1 

Costs  reported  in  this  section  are  taken  from  Ref.  2. 
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A.  RESPONSIVENESS 


Software  is  often  unresponsive  to  user  needs.  The  dearth 
of  techniques  for  specifying  requirements  and  the  complexity  of 
software  systems  create  a  situation  in  which  there  is  minimal 
understanding  of  the  intended  user's  real  requirement  by  those 
who  must  design  and  Implement  the  software.  By  the  time  the 
system  is  sufficiently  near  completion  for  the  user  to  try  it, 
most  decisions  are  irrevocably  built  into  the  design.  There 
is  an  almost  universal  disregard  f*or  the  building  of  prototype 
systems  to  resolve  or  clarify  user  requirements.  The  result, 
all  too  often,  is  software  that  is  of  little  value  to  anyone. 

It  should  be  noted  that  the  need  for  prototyping  applies  to  the 
common  language  effort  as  it  does  to  other  softv;are  designs. 

B.  RELIABILITY 

Software  reliability  resembles  hardware  reliability  in 
that  it  is  possible  to  measure  the  mean  time  between  failures 
and  in  that  failures  are  not  always  reproducible  under  seem¬ 
ingly  similar  circumstances.  In  reality,  however,  software 
faults  are  quite  different:  software  does  not  degrade  with 
time;  all  software  faults  are  inherent  in  its  design;  once  cor¬ 
rected,  a  software  fault  will  not  reoccur;  and  exactly  the  same 
faults  will  occur  under  the  same  circumstances  in  multiple  de¬ 
ployment  of  software.  Unreliable  software  has  Just  two  causes: 
incorrect  programs  and  erroneous  input  data.  Incorrect  pro¬ 
grams  result  from  transcription  errors,  lack  of  understanding 
of  the  program  by  its  authors,  and  the  use  of  logically  incor¬ 
rect  algorithms.  Software  faults  from  bad  data  indicate  lack 
of  robustness  in  the  program  design,  and,  more  specifically, 
failure  of  the  program  to  validate  the  input  for  conformity 
with  the  program's  input  assumptions. 

Another  difficulty  of  softviare  reliability  is  that  the 
problem  is  often  confused  with  the  problems  of  changing  user 
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requirements  and  software  maintainability.  Thus,  although  a 
program  might  be  correct  and  its  correctness  v;lll  not  degrade 
with  time,  user  needs  may  change  so  that. the  program  does  not 
provide  a  useful  service.  Lack  of  maintainability  and  modifi¬ 
ability  of  progrsims  may  Impair  the  ability  to  repair  software 
design  errors.  In  some  situations,  the  effects  of  a  change 
may  be  so  opaque  that  there  can  be  no  confidence  that  changes 
will  not  introduce  as  many  errors  as  they  correct! 

»' 

Software  reliability  is  particularly  important  in  the 
military  environment  where  errors  can  have  catastrophic  con¬ 
sequences.  It  should  also  ue  remembered  in  this  regard  that 
redundant  deployment  and  voting  will  not  reduce  or  protect 
against  software  faults. 

C.  FLEXIBILITY/MAINTAINABILITY 

Software  is  inherently  flexible,  modifiable,  and  amenable 
to  change.  It  is  soft  in  the  sense  that  it  is  a  collection  of 
ideas,  abstractions,  and  information  without  an  essential  phys¬ 
ical  form.  The  only  rationale  for  implementing  a  system  with 
software  instead  of  hardware  is  flexibility.  Software  is  used 
when  the  task  has  a  short  lifetime  and  will  soon  be  supplanted 
by  another  task  requiring  a  different  program,  when  the  task 
is  sufficiently  complex  that  many  changes  and  modifications 
will  be  required  to  refine  it  into  a  workable  system,  when  there 
is  expectation  for  growth  in  the  system  and  continued  revision 
of  the  system  requirements,  and  when  the  system  is  sufficiently 
unique  that  the  economies  are  in  specializing  a  general-purpose 
system  Instead  of  building  a  hard  system. 

Unfortunately,  software's  inherent  flexibility  is  seldom 
available  in  practice.  Software  is  pure  design,  with  only  sym¬ 
bolic  form.  As  such,  any  change  or  modification  to  software  is 
a  change  in  its  design.  Design  changes  are  easy  only  if  we  are 
not  concerned  with  their  consequences.  To  make  design  changes 
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with  predictable  consequences,  we  must  thoroughly  understand 
the  design,  what  aspects  of  the  design  will  be  affected  by  our 
changes,  and  how  those  piecewise  effects  will  affect  the  whole. 
Thus,  purposeful  software  change  and  modification  and  its  de¬ 
sign  of  flexibility  are  determined  by  the  completeness,  cor¬ 
rectness,  end  understandabllity  of  its  design  and  documenta¬ 
tion. 

D.  EXCESSIVE  COST 

There  are  wide  variances  in  software  productivity,  reli¬ 
ability,  flexibility,  and  cost.  Programmers  purportedly  pro¬ 
duce  an  average  of  10  debugged  instructions  per  day,  but  the 
variance  is  at  least  from  1  to  100  instructions  per  day.  Soft¬ 
ware  systems  are  not  built  from  existing  off-the-s.^ielf  or  re¬ 
usable  parts,  but  from  scratch  each  time,  using  the  prlnltlves 
of  the  current  programming  language.  Programming  tools  with 
demonstrated  software  productivity  increases  of  at  least  two 
decimal  orders  of  magnitude  for  large  complex  software  systems 
in  research  environments  are  unavailable  for  the  military  user. 
In  many  DoD  applications,  assembly  languages  are  still  widely 
used  (and  some  would  argue,  to  advantage,  over  the  available 
HOLs).  Finally,  the  lack  of  visibility  of  software  to  manage¬ 
ment,  inaccessibility  of  software  costs,  and  failure  to  give 
software  the  same  scrutiny  as  hardware  in  the  development  of 
military  systems  creates  a  situation  in  which  there  is  little 
cost  accountability. 

Computer  resource  limitation  is  probably  a  large  factor  in 
excessive  costs.  It  is  Just  as  easy  to  add  functions  to  a  sys¬ 
tem  that  is  full  as  It  is  to  augment  one  that  has  plenty  of 
slack.  One  reason  that  promising  tools  are  not  being  widely 
used,  that  assembly  language  use  is  continuing,  etc.,  is  that 
computer  i-esource  limitations  (fixed  at  the  time  of  software 
design)  force  emphasis  on  minimum  possible  code  per  function. 
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This  may  also  account  for  the  dearth  of  off-the-shelf  software. 
Most  software  customers  want  the  product  they  buy  to  be  small, 
fast,  and  cheap.  They  ask,  why  add  extra  effort  and  resources 
to  provide  general  capabilities  that  are  not  needed  for  their 
particular  project? 

E.  TIMELINESS 

Many  software  projects  have  gone  awry  for  lack  of  calendar 
time.  The  reasons  are  many:  estimating  techniques  are  poorly 
developed;  effort  is  often  confused  with  progress  in  software 
development,  there  is  sometimes  the  false  assumption  that  men 
and  months  are  Interchangeable;  uncertainty  of  estimates,  which 
assures  that  only  the  most  stubborn  software  managers  will  stick 
by  pessimistic  time  estimates;  lack  of  engineering  discipline 
in  software  development  which  makes  it  difficult  to  monitor 
progress;  and  adding  additional  manpower  when  schedule  slip¬ 
pages  are  recognized. 

In  many  systems,  including  large  military  systems,  indi¬ 
rect  costs  from  software  slippages  can  far  exceed  the  direct 
costs  of  the  software.  Deployment  of  a  recent  Command  and  Con¬ 
trol  system,  with  an  expected  life  of  7  years,  was  delayed  6 
months  because  the  software  was  not  ready.  Since  the  total 
system  cost  was  about  $1.*<  billion,  the  6-month  loss  of  system 
capability  represents  a  $100  million  indirect  cost  (Ref.  1). 

F.  TRANSFERABILITY 

Software  transferability  is  a  special  case  of  flexibility, 
but  one  with  obvious  economic  consequences.  Transferable  soft¬ 
ware  Ccin  be  borrowed  from  one  project  or  task  and  adjusted  or 
modified  to  suit  another.  For  the  present,  a  realistic  goal  of 
transferability  is  that  it  be  less  expensive  to  move  software 
from  one  machine  to  another  than  to  write  it  from,  scratch.  The 
costs  of  transferring  software  cannot  be  eliminated,  and  if 
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object  efficiency  is  important,  cannot  be  done  entirely  auto¬ 
matically.  Successful  reuse  of  software  has  been  almost  ex¬ 
clusively  confined  to  mathematical  subroutines  in  FORTRAN,  data 
processing  application  packages  in  COBOL,  and  a  few  follow-on 
systems  which  borrowed  extensively  from  their  predecessors.  A 
key  ingredient  in  each  of  these  was  the  use  of  the  same  program¬ 
ming  language.  It  may  not  be  possible,  or  even  desirable,  to 
reuse  the  top-level  structures  of  applications  software,  J>jut 
there  is  little  reason  why  software  design,  development,  test, 
£ind  maintenance  tools  and  aids  and  other  support  software  should 
not  be  reusable.  Neither  is  there  reason  to  believe  that  lower- 
level  software  building  blocks  used  to  compose  specific  tasks 
must  be  unique  to  that  task  and  cannot  be  constructed  to  ad¬ 
vantage  for  common  use  throughout  that  application  area.  There 
was  a  time  when  functional  commonality  seemed  as  incredible  in 
scientific  and  data  processing  applications  as  it  now  does  to 
some  in  weapons  systems,  command  and  control,  communications, 
and  avionics. 

G.  EFFICIENCY 

In  software,  efficiency  is  usually  taken  to  mean  the  time 
and  space  utilization  of  a  running  computer  program.  Efficiency 
in  this  form  is  important  because  in  some  applications  there  are 
critical  paths  in  the  software  which  do  press  the  available  re¬ 
sources  to  their  limit.  Some  applications  (e.g.^  simulation) 
have  computational  requirements  in  excess  of  even  the  largest 
computers,  while  mobile  systems  (e.g.^  avionic,  shipboard,  and 
van-mounted)  often  have  environmental  requirements  limiting 
their  capability  and  performance.  There  are  situations  in  which 
object  code  and  object  data  representation  are  '’rltlcal.  In 
a'/  case,  resources  should  not  be  wasted. 

There  was  a  time  when  computer  hardware  was  the  major  cost 
component  of  computer  systems  and  hardware  logic  speed  the  major 
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performance  limitation.  Today,  software  costs  far  exceed  hard¬ 
ware  costs,  and  in  many  applications,  the  memory,  peripheral, 
and  communications  speed  are  the  limiting  performance  factors. 
Software  costs  increase  rapidly  as  the  computer  reaches  satu¬ 
ration.  Major  savings  may  be  realized  by  planning  for  50  to 
75  percent  computer  saturation,  but  the  tendency  remains  to 
consider  only  hardware  in  the  initial  design  and  to  assume  that 
the  software  will  adjust. 

If  efficiency  is  taken  in  t’le  broader  sense  of  optimal  use 
of  all  resources  to  minimize  total  cost  (either  life-cycle  or 
initial  development  only),  it  becomes  clear  that  there  are  many 
trade-offs,  and  that  coding  tricks  at  the  machine  level  seldom 
can  make  a  significant  contribution.  Real  efficiency,  even  as 
measured  by  execution  times,  results  first  from  the  use  of  the 
most  efficient  algorithm,  independent  of  its  implementation, 
and  secondly  from  identifying  and  Improving  those  sm.a.''.l  parts 
of  programs  constituting  the  majority  of  the  execution  costs. 
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IV. 


LANGUAGE  DESIGN  CRITERIA 


The  Common  HOL  effort  Is  concerned  with  the  selection  of 
a  programming  language  which  is  expected  to  be  used  in  a  vari¬ 
ety  of  applications,  particularly  those  in  which  there  is  cur¬ 
rently  no  widely  used  language.  Implicit  in  this  effort  is 
the  expectation  that  a  large  number  of  programming  language 
users  will  adopt  programming  language  new  to  them.  Any  change 
Involves  costs,  and  can  be  Justified  only  if  the  resulting 
savings  exceed  the  total  costs  of  the  change. 

Success  in  the  Common  HOL  effort  depends  on  the  accessi¬ 
bility,  utility,  and  applicability  of  the  selected  language  for 
use  in  individual  application  areas,  on  the  benefits  to  be  de¬ 
rived  from  its  use,  and  on  the  ability  of  the  language  to  re- 
mc in  uniform  and  stable  for  an  extended  period.  Potential  us¬ 
ers  of  a  language  will  not  adopt  it  if  it  falls  to  satisfy  the 
special  needs  of  their  application.  The  help  a  language  pro- 
vlaes  in  reducing  software  problems  determines  its  utility 
and  the  benefits  to  be  derived  from  its  use.  Among  the  major 
benefits  of  using  a  common  language  are  reduced  training  costs, 
greater  personnel  mobility,  wider  use  of  common  tools,  and  ac¬ 
cess  to  off-the-shelf  software  components.  These  latter  bene¬ 
fits  depend  primarily  on  the  stability  of  the  language  defir-’ - 
tion,  the  uniformity  of  its  Implementation,  and  an  effective 
program  of  awareness  of  what  is  on  the  shelf. 

Selection  of  a  good  or  best  language  to  serve  as  a  com¬ 
mon  language  implies  use  of  value  Judgments  which  can  have  mean¬ 
ing  only  with  reference  to  criteria.  Criteria  must  be  estab¬ 
lished  to  provide  a  basis  for  measuring  the  suitability  and  ap¬ 
propriateness  of  alternative  designs  during  the  language  selection 
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process.  Criteria  tend  to  be  general,  imprecise,  and  not  sub¬ 
ject  to  quantative  measure,  but  they  should  be  unambiguous  and 
provide  a  framework,  a  set  of  guidelines,  which  can  be  used  to 
derive  more  specific  characteristics  that  are  subject  to  meas¬ 
urement  . 

The  language-design  criteria  belov;  reflect  the  three  goals 
of  (1)  satisfying  the  specialized  application  requirements,  (2) 
resolving  existing  software  problem.s,  and  (3)  assuring  that  the 
language  can  become  a  comm.on  language. 

A.  CRITERIA  TO  SATISFY  SPECIALIZED  APPLICATION  REQUIREMENTS 

1 .  Flexibility  in  Software  Design  Criteria 

Software  requirements  of  each  system  vary,  depending  upon 
the  mission.  The  relative  importance  of  execution  efficiency, 
memory  utilization,  program  modifiability,  reliability,  program 
production  tim.e,  and  the  many  other  program  design  criteria  vary 
widely  from  application  to  application,  and  even  among  the  com¬ 
ponents  of  a  single  system.  Consequently,  the  optimization  cri¬ 
teria  for  software  programs  should  not  be  built  into  the  pro¬ 
gramming  language.  Instead,  the  language  should  be  sufficiently 
robust  (at  compilation  time)  to  allow  the  software  designer  to 
optimize  his  programs  according  to  the  criteria  of  greatest  im¬ 
portance  to  his  project.  The  software  optimization  criteria 
should  be  bound  at  program  compilation  time  and  not  at  language 
design  time. 

2 .  Fault-Tolerant  Programs 

In  many  weapons  systems  and  control  applications,  it  is  es¬ 
sential  that  the  programxiing  language  permit  the  description  of 
computations  which  will  continue  to  operate  in  the  presence  of 
faults,  v;hether  in  the  computer  hardware,  in  input  data,  in  op¬ 
erator  procedures,  or  in  other  software.  Crucial  to  fault-tole¬ 
rant  programs  is  the  ability  of  the  program  to  specify  the  ac¬ 
tion  to  be  taken  for  all  run  time  exception  conditions. 
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3.  Machine-Dependent  Programs 


There  are  several  hundred  models  of  computers  in  use  in 
DoD.  In  many  applications,  they  have  unique  configurations 
not  compatible  with  general-purpose  installations.  These  com¬ 
puters  may  interface  v;lth  sensors  or  control  equipment  such  as 
a  radar.  There  are  sometimes  specialized  computer  equipments 
such  as  associative  memories,  real-time  clocks,  analog  devices, 
and  special-function  boxes  to  aid  particular  computations. 
Programs  must  have  access  to  these  machine-dependent  capabili¬ 
ties  . 

4.  Real-Time  Capability 

Some  applications  require  that  faces  be  between  the  com¬ 
putational  solution  and  equlpm.ent  or  people  in  real  time.  The 
programming  language  used  in  these  applications  must,  there¬ 
fore,  give  access  to  a  real-time  clock,  allow  specification  of 
the  maximum  duration  for  execution  of  designated  parts  of  the 
computation,  and  permit  the  programmer  to  specify  the  action 
to  be  taken  upon  passage  of  designated  time  intervals.  These 
applications  include  monitoring  of  sensors;  control  of  equip¬ 
ment;  display;  and  operator  input  processing  in  applications 
such  as  avionics,  command  and  control,  communications,  and 
training.  Real-tlm.e  programs  may  require  access  of  time  of  day 
and  Interval  timers,  the  ability  to  respond  at  periodic  inter¬ 
vals,  to  service  interrupts  within  a  limited  tlm.e,  and  to  pre¬ 
dict  computation  times  accurately.  The  time  quantities  which 
must  be  dealt  with  vary  from  microseconds  for  device  interface 
handling,  through  milliseconds  in  sensor  monitoring,  seconds 
in  control  applications,  to  days  in  report  generation. 

5.  j/stem-Proqramminq  Capability 

Many  applications  use  dedicated  computers  because  they 
cannot  afford  the  overhead  and  do  not  require  the  generality  of 
general-purpose  operating  systems.  For  exam.ple,  avionics,  tac¬ 
tical  systems,  communications,  and  process  control  applications 
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include  development  of  specialized  executive  systems.  System 
progrcimming  capability  is  also  needed  for  the  development  cind 
maintenance  of  general-purpose  operating  systems  and  other  sup¬ 
port  software. 

6.  Data  Base  Handling  Capability 

In  many  applications,  including  command  and  control;  data 
processing;  training;  and  software  design*,  development,  6ind 
maintenance  it  is  necessary  to  access,  manipulate,  and  display 
large  quantities  of  data-  Much  of  this  data  is  symbolic  or 
textual  rather  than  numeric,  and  must  be  organized  in  an  or¬ 
derly  and  accessible  fashion.  Memory  space  rather  than  execu¬ 
tion  time  is  often  the  critical  resource  in  data  handling  ap¬ 
plications;  large  peripheral  storage  devices  must  be  employed, 
and  programs  must  be  able  to  process  densely  packed  data. 

7 .  Numeric  Processing  Capability 

Numeric  processing  capability  is  essential  to  many  appli¬ 
cations,  including  simulation,  sensor  processing,  equipment  con¬ 
trol,  and  general-purpose  engineering  and  scientific  applica¬ 
tions.  In  some  environments,  only  fixed-point  arithmetic  is 
available  on  the  object  computers. 

B.  CRITERIA  ADDRESSING  EXISTING  SOFTWARE  PROBLEMS 
1 .  Simple  Source  Language 

The  role  of  unnecessary  complexity  as  the  main  source  of 
problem.s  in  the  use  of  high-order  programming  languages  cannot 
be  overemphasized.  Sim.plicity  in  a  programming  language  means 
a  small  language  with  few  special  cases,  each  feature  simple 
in  meaning  and  implementation,  uniform  syntactic  forms  and 
consistent  interpretations  when  several  special  cases  must  be 
provided.  There  are  conglomerate  languages  so  large,  diverse, 
and  complex  that  programmers  are  not  expected  to  understand 
the  whole  language,  but  only  those  subsets  applicable  to  their 
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problems.  Partitions  between  subsets  are  often  not  well  drawn 
and  there  is  little  consistency  among  the  subsets,  so  that  when 
something  goes  wrong  in  a  program  it  may  invoke  language  fea¬ 
tures  totally  foreign  to  the  authors*  understanding.  Even  if 
the  system  detects  the  error,  the  diagnostic  will  not  be  mean¬ 
ingful  to  the  programmer.  Ad  hoc  language  designs  which  have 
attempted  to  satisfy  every  application  by  providing  specialised 
features  for  each  special  problem  result  in  languages  that  are 
difficult  to  learn,  impossible  to  Implement  consistently,  and 
which  guarantee  unreadable,  inflexible,  and  nontransf enable 
software . 

Untimely  delivery  of  software  is  primarily  the  result  of 
an  inability  to  integrate  the  separate  components  of  a  large 
software  package.  The  Integration  problem  is  a  direct  result 
of  software  interfaces  too  complex  and  ill-defined  to  be  fully 
understood  in  the  same  way  by  all  parties  using  them.  Lack  of 
software  flexibility  and  maintainability  is  the  unavoidable 
consequence  of  programs  and  programming  languages  so  complex 
that  no  one  can  predict  the  consequences  of  program  changes. 
Language  complexity  contributes  to  the  nontransferability  by 
ensuring  that  few  Installations  will  be  able  to  afford  imple¬ 
mentation  of  the  full  language  and  that  no  two  installations 
will  implement  features  with  exactly  the  same  semantics.  The 
result  is  implementation-dependent  programs  incomprehensible 
and  unusable  anywhere  but  where  written.  Software  productivity 
depends  on  the  ability  to  reuse  existing  software,  on  deslcn, 
coding,  and  maintenance  efficiency,  and  on  the  usability  of  the 
software  design,  development,  and  maintenance  tools.  The  only 
hope  of  significantly  improving  software  productivity  is  the 
ability  to  reuse  software,  particularly  support  software  and 
software  tools.  This  cannot  happen  as  long  as  programs  are  in¬ 
comprehensible,  unpredictable,  and  unmcdlflable .  Finally, 
efficient  programs  cannot  be  written  in  languages  that  em.ploy 
highly  specialized  complex  features  which  do  not  themselves 
have  efficient  representations  in  obiect  machines. 
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This  is  not  to  claim  that  the  use  of  simple  programming 
languages  will  solve  the  software  problems.  If  that  were  true, 
machine  languages  would  be  ideal.  Rather,  the  claim  is  that 
the  problems  cannot  be  solved  with  complex  languages  and  that 
many  of  the  current  problems  have  been  aggravated  by  the  use  of 
unnecessarily  large  and  cojnplex  programming  languages. 

2 .  Readab 1 e/Unders tandabi e  Programs 

In  the  development  of  large  software  systems  which  must  be 
integrated  from  many  separately  developed  parts  or  software  sub¬ 
systems,  have  long  lifetimes,  and  must  go  through  many  modifica¬ 
tions  to  their  functional  requirements,  it  Is  essential  that  the 
programs  be  readable  and  understandable  by  their  authors  and 
malntalners.  Only  when  the  programmer  thoroughly  understands  his 
own  programs  can  he  convince  himself  or  anyone  else  of  their  cor¬ 
rectness.  We  cannot  accurately  predict  the  effect  of  a  program 
if  we  cannot  understand  it  and  we  cannot  modify,  repair,  or  ex¬ 
tend  a  program  if  we  cannot  predict  the  impact  of  changes. 

3.  Correct  Translator 

The  programmer  must  have  confidence  in  the  compiler.  The 
implementation  must  be  consistent  with  the  language  semantics, 
it  must  report  errors  rather  than  compile  a  garbage  object  code, 
it  must  produce  the  object  code  a  good  programmer  would  expect, 
and  it  should  not  change  the  meaning  of  programs  from  time  to 
time.  More  simply,  it  should  be  correct,  consistent,  and  pre¬ 
dictable.  The  language  features  it  must  Implement,  their  form 
in  the  source  language,  and  the  quality  of  the  source  language 
definition  affects  the  ability  of  the  translator  to  meet  these 
goals . 

4 .  Error- Intolerant  Translator 

The  issue  here  is,  when  are  programming  errors  to  be  de¬ 
tected:  during  the  design,  during  program  development,  during 

system  validation  and  test,  or  while  the  program  is  in  use?  In 


many  DoD  applications,  errors  discovered  in  operational  use  can 
have  catastrophic  consequences.  System  test  and  validation  is 
an  ideal  time  to  build  confidence  in  a  system  and  to  test  the 
most  common  cases.  It  is,  however,  impossible  to  test  every 
case,  2Uid  there  must  be  confidence  that  the  limited  tests  em¬ 
ployed  are  indicative  of  the  total  program  reliability.  Errors 
should  be  detected  during  the  design  and  development  phases. 

'f 

The  translator  can  help  by  reporting  all  errors  which, it  can 
detect.  The  number  and  Importance  of  these  will  be  small  (i.e., 
syntax  only)  if  the  source  language  is  only  a  coding  language. 
Reducing  the  syntactic  choices  of  the  user  by  restricting  the 
set  of  acceptable  program  strings  can  increase  the  distance  be¬ 
tween  correct  programs  and  increase  the  probability  that  syntax 
errors  will  result  in  syntactically  incorrect  programs,  but  this 
is  of  very  limited  help.  The  important  errors  are  semantic  and 
can  be  detected  by  the  compiler  only  if  the  programming  langu¬ 
age  is  a  design  and  documentation  language  as  well  as  a  coding 
language.  That  is,  if  it  allows  specification  of  the  progi-am- 
mers  Intent  as  well  as  his  actions  (e.g.,  range  and  types  of 
variables),  it  allows  redundant  specifications  {e.g.,  types  of 
formal  and  actual  parameters),  it  does  not  violate  his  inten¬ 
tions  {e.g.,  no  implicit  type  conversions),  permits  him  to  iden¬ 
tify  the  parts  of  the  program  in  which  a  program  component  will 
be  used  {e.g.,  scope  of  access  specification),  and  allows  him 
to  deny  access  to  nonessential  properties  of  his  data  and  pro¬ 
grams.  Each  of  these  provides  information  which  allows  the 
translator  to  check  the  program  design  for  semantic  consistency 
and  to  verify  that  the  programmer  has,  in  fact,  conformed  to 
his  own  conventions  and  stated  intent.  These  same  specifica¬ 
tions  will  also  contribute  to  the  readability  and  maintainabil¬ 
ity  of  the  program.. 

The  goal,  of  course,  should  not  be  to  maxlm.lze  the  number 
of  detectable  errors,  but  rather  to  minimize  the  number  of  non- 
detectable  errors,  the  difference  being  that  the  language  should 
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be  first  concerned  with  the  prevention  of  errors  and  secondly, 
with  the  detection  of  errors  which  cannot  be  prevented  by  the 
language.  Many  errors  are  prevented,  for  example,  when  the 
HOL  does  not  permit  run  time  modifications  to  executable  code 
or  does  not  permit  Boolean  operations  on  floating  point  values. 
In  any  case,  the  language  design  should  attempt  to  minimize 
the  kinds  of  errors  which  can  occur  and  should  attempt  to  maxi¬ 
mize  the  number  of  those  which  are  detectable  by  a  translator. 
Finally,  any  translator  for  the  HOL  should  report  all  errors 
which  it  can  detect. 

5.  Efficient  Object  Code 

Software  should  strive  to  make  optimal  use  of  all  the  re¬ 
sources  associated  with  the  design,  development,  use,  and  main¬ 
tenance  of  the  software.  In  some  DoD  software  systems,  the  ma¬ 
jor  costs  are  in  hardware  because  of  multiple  deployment  (e.g., 
fire  control)  or  are  subject  to  computer  hardware  constraints 
because  of  the  environment  (e.g.,  avionics).  In  some  control 
systems,  there  are  critical  time  constraints  which  are  diffi¬ 
cult  for  even  machine  language  programs  to  meet;  in  some  simu¬ 
lation  problems,  the  full  job  is  still  beyond  the  capabilities 
of  even  the  largest  computers,  eind  in  some  data  processing  ap¬ 
plications,  limited  memory  resources  require  shuffling  of  large 
quantities  of  data  between  main  and  peripheral  memories  and 
create  a  bottleneck  at  the  I/O  Interface.  In  all  these  appli¬ 
cations,  the  efficiency  of  program  and/or  data  object  represen¬ 
tations  can  be  very  Important.  Optimal  program  design,  of 
course,  must  be  relative  to  oome  design  criteria  which  are  meas¬ 
ured  in  terms  of  some  resource,  such  as  time,  space,  manpower, 
or  dollars.  Optimal  program  design  does  not  imply,  for  example, 
that  compile  time  resources  should  be  wasted  in  squeezing  out 
unneeded  object  efficiency. 
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C.  CRITERIA  TO  ASSURE  A  COMMON  PROGRAMMING  LANGUAGE  PRODUCT 
1 .  Complete  Source  Language 

Every  user  level  aspect  of  the  language  should  be  speci¬ 
fied  in  its  defining  documentation.  None  should  be  left  to  be 
made  arbitrarily  and  uniquely  by  each  translator,  operating 
system,  and  object  machine.  The  language  proliferation  prob¬ 
lem  stems  primarily  from  development  of  evermore  new  incompat¬ 
ible  versions  of  existing  languages.  In  many  cases,  new  lang¬ 
uages  are  developed  for  sound  reasons,  but  the  effect  is  the 
same.  In  some  cases,  the  new  language  is  given  a  new  name,  in 
others,  it  retains  the  old  name  and  becomes  incompatible  dia¬ 
lect.  In  many  Instances,  it  is  not  so  much  that  the  new  ver¬ 
sion  violates  previous  standards,  but  that  the  standards  are  so 
incomplete  and  ambiguous  that  commonality  is  impossible.  Even 
worse,  many  programming  language  definitions  and  standards  in¬ 
tentionally  leave  portions  of  the  semantics  unspecified  with 
the  intent  that  they  will  be  provided  by  the  translator.  This 
may  be  necessary  for  the  appearance  of  comm.onallty  when  incom¬ 
patible  compilers  for  a  language  already  exist,  but  certainly 
not  for  a  new  language.  Commonality,  in  more  than  name,  re¬ 
quires  that  the  language  specification  be  complete.  Every  de¬ 
cision  made  in  the  programming  process  should  be  made  irrevoc¬ 
ably  in  the  language  design  or  the  choice  should  be  given  ex¬ 
plicitly  to  the  programmer. 

This  does  not  mean  that  a  program  must  be  implemented  in 
the  same  way  on  all  object  machines,  only  that  the  resulting 
semantics  be  the  same  in  all  ways  important  to  the  program 
logic.  The  user  should  not  have  to  overspecify  his  programs; 
he  should  be  able  to  leave  don't  care  and  don  ' t-care-within~ 
limits  conditions  tc  the  translator.  For  example,  he  might  be 
able  to  specify  the  minimal  numeric  precision  required  by  his 
program  with  the  exact  implementation  determined  by  the  trans¬ 
lator  and  object  machine.  The  order  of  evaluation  of  terms  in 


an  expression  or  of  the  operators  In  a  sequence  of  associative 
operators  should  be  left  to  the  translator  when  it  does  not 
affect  the  computation. 

2 .  Wide  ApplicabiTity 

The  wide  use  of  a  very  small  number  of  programming  langu¬ 
ages  Is  desirable  for  many  reasons.  Training  costs  are  reduced 
and  personnel  become  more  versatile.  Project  costs  should  be 
less,  because  existing  software  can  be  reused.  Pf-ogrammlng  ' 
costs  should  be  lower  because  funds  can  be  expended  on  improv-- 
ing  existing  software  tools  and  building  more  powerful  tools. 
Increasingly,  applications  are  net  pure;  they  may  be  primarily 
numerical  computation,  report  generation,  sensor  processing, 
process  control,  file  searching,  etc.,  but  each  has  Ingredients 
of  several  other  applications.  Special-purpose,  problem-ori¬ 
ented  languages  lack  the  generality  and  adaptability  to  grow 
with  the  applications.  Confidence  that  the  next  project  or 
assignment  will  use  the  same  language  creates  Incentives  at 
both  the  management  and  programmer  level  to  develop  flexible 
and  reusable  software. 

3 .  ImpTementabI e 

A  programming  language  will  be  widely  used  only  If  It  Is 
capable  of  Inexpensive  translation  Into  object  computer  pro¬ 
grams.  If  the  language  Is  simple  and  easy  to  Implement,  the 
cost  of  Implementation  will  be  lower  and  translators  will  be 
more  widely  available.  Potential  users  will  like  It  and  want 
to  use  It  only  If  the  cost  in  machine  resources  and  elapsed 
time  for  translation  is  reasonable.  The  smaller  the  transla¬ 
tor  and  the  smaller  the  machines  which  can  host  the  translator, 
the  larger  the  number  of  users. 

4.  Static  Design 

There  can  be  no  commonality  If  the  programming  languages, 
are  constantly  changing.  Projects  often  develop  their  own 
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compilers.  These  compilers  do  not  Implement  exactly  some  ex¬ 
isting  source  language,  but  are  extended  subsets  which  attempt 
to  incorporate  the  latest  software  technology  and  special  fea¬ 
tures  useful  to  their  project  while  omitting  seldom-used  fea¬ 
tures.  This  approach,  while  providing  specialized  tools  sorne- 
times  well-suited  to  the  task  at  hand.  Increases  the  research 
content,  risk,  and  cost  of  the  project.  The  alternative  is  to 
draw  a  distinct  line  between  research  in  programming  languages 
and  engineering  development  of  a  language.  A  language  can  be 
built  as  an  engineering  development,  incorporating  the  current 
state  of  the  art  but  not  going  beyond  it;  its  design  can  be 
frozen  and  the  language  used  in  that  form  for  an  extended  period. 
A  willingness  to  freeze  languages  and  to  accept  the  best  tech¬ 
nology  of  some  past  moment  is  essential  to  obtain  the  benefits 
of  commonality.  Research  on  software  technology,  management, 
language  features,  and  language  design  should  continue  in  par¬ 
allel  with  use  of  a  common  language.  Growth  and  improvement 
in  production  programming  languages  should  be  limited  to  dis¬ 
crete,  clearly  defined  points  when  there  are  major  Improvements 
to  be  incorporated  rather  than  on  a  continuous  basis. 

A  static  design  cannot  be  maintained  without  controls. 

Both  implicit  and  explicit  controls  will  probably  be  needed. 
Explicit  controls  might  Include  language  standards,  configura¬ 
tion  management  of  language  implementations,  and  policy  requir¬ 
ing  use  of  the  common  language.  Implicit  controls  are  at  least 
as  Important.  They  might  Include  economic  Incentives,  such  as 
low  cost  access  to  existing  support  software,  software  develop¬ 
ment  aids  and  application  packages,  lower-risk  developments, 
and  greater  availability  of  trained  programming  personnel. 


5.  Reusabi 1 i ty 


A  common  language  alone,  even  if  it  has  easily  accessible, 
compatible,  and  efficient  implementations,  is  insufficient  to 
encourage  the  development  of  flexible  and  reusable  software. 
Reusability  does  not  result  merely  from  the  use  of  a  common 
leinguage.  A  major  problem  in  writing  reusable  software  is 
that  the  generality  required  for  reusability  precludes  it 
from  being  acceptably  efficient  in  many  applications.  General- 
purpose  routines  will  be  widely  used  only  if  it  is  easy  to 
tailor  them  to  efficient,  special-purpose  variants.  Most  desir¬ 
ably,  these  specializations  would  be  made  automatically  by  the 
compiler  when  constant  arguments  are  used,  or  semiautomatically , 
as  when  the  programjner  specifies  that  a  call  is  to  be  compiled 
as  an  open,  rather  than  closed,  subroutine.  Language  features 
should  be  chosen  to  encourage  the  development  and  use  of  reus¬ 
able  software. 

6.  A  Pedagogical  Language 

A  good  pedagogical  programming  language  Is  one  which  is 
easy  to  learn  and  well  suited  to  teaching  programming  method¬ 
ology  and  techniques.  In  applications  for  which  there  is  cur¬ 
rently  no  common  language,  selection  of  a  common  easy-to-learn 
language  will  reduce  the  difficulty  and  cost  of  adopting  a  com¬ 
mon  language.  A  language  well-suited  for  teaching  and  learning 
programming  methodology  and  techniques  is,  of  course,  also  well- 
suited  for  applying  those  methods  and  techniques. 

Already,  in  the  short  time  of  this  effort,  unsolicited  in¬ 
terest  in  using  a  common  DoD  language  has  been  shown  by  univer¬ 
sities.  They  not  only  need  a  modern  pedagogical  language,  but 
also  one  which  has  many  users  outside  the  academic  community. 

Few,  if  any,  of  the  commercial  and  academic  programming  languages 
satisfy  both  requirements. 
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V.  THE  NEEDED  CHARACTERISTICS 


The  set  of  characteristics  prescribed  below  represents  a 
synthesis  of  the  requirements  submitted  by  the  Military  Depart¬ 
ments  and  Is  intended  to  be  consistent  with  the  language  cri¬ 
teria  of  Section  IV,  self-consistent,  and  achievable  with  ex¬ 
isting  computer  software  and  hardware  technology.  The  needed 
characteristics  are  the  requirements  to  be  satisfied  by  an  ex¬ 
isting,  modified,  or  new  language  selected  as  a  common  language. 
The  characteristics  prescribe  capabilities  and  properties  which 
a  common  DoD  language  should  possess,  but  are  not  intended  to 
impose  any  particular  language  features  or  mechanization  of 
those  capabilities. 

The  large  number  of  characteristics  reflects  an  attempt  at 
thoroughness  in  dealing  with  the  relevant  issues.  Similarly, 
the  length  of  the  discussion  for  many  items  reflects  the  need 
to  resolve  the  ambiguities,  examine  the  implications,  and  demon¬ 
strate  the  feasibility  of  the  compendious  statement  introducing 
that  characteristic.  Because  the  characteristics  address  issues 
in  the  design,  implementation,  and  use  of  the  language  and  prop¬ 
erties  of  the  resulting  product,  there  should  be  no  correlation 
between  the  number  of  characteristics  discussed  here  and  the 
number  of  features  in  a  language  which  satisfies  these  character¬ 
istics.  Many  of  the  characteristics  will  influence  the  choice 
of  many  features,  and  every  feature  will  be  influenced  by  many 
of  the  needed  characteristics  that  good  language  design  is  a 
unification  process.  Any  language  that  satisfies  these  character¬ 
istics  must  be  smaller  and  simpler  than  the  set  of  issues  un¬ 
derlying  its  choice. 


71 


The  header  of  each  Item  gives  a  general  description  of  the 
needed  language  characteristic j  while  the  subsequent  paragraph(s) 
of  its  body  provide  clarification,  discuss  some  of  the  implica¬ 
tions  and  problems,  provide  the  rationale  behind  its  inclusion, 
and  further  detail  the  requirement.  The  entire  text,  not  Just 
the  headers,  constitutes  the  requirements. 

A.  DATA  AND  TYPES 

Al.  The  language  will  be  typed.  The  type  (or 
mode)  of  all  variables ^  components  of  com¬ 
posite  data  structures ^  expressions ^  opera- 
tionSt  and  parameters  will  he  determinable 
at  com.pile  time  and  unalterable  at  run  time. 

The  language  will  require  that  the  type  of 
each  variable  and  component  of  composite 
data  structures  he  explicitly  specified  in 
the  source  programs . 

By  the  type  of  a  data  object  is  meant  the  set  of  objects 
themselves,  the  essential  properties  of  those  objects,  and  the 
set  of  operations  which  give  access  to  and  take  advantage  of 
those  properties.  The  author  of  any  correct  program  in  any 
programming  language  must,  of  course,  know  the  types  of  all  data 
and  variables  used  in  his  programs.  If  the  program  is  to  be 
maintainable,  modifiable,  and  comprehensible  by  someone  other 
than  its  author,  then  the  types  of  variables,  operations,  and 
expressions  should  be  easily  determined  from  the  source  program. 
Type  specifications  in  programs  provide  the  redundancy  necessary 
to  verify  automatically  that  the  programmer  has  adhered  to  his 
own  type  conventions.  Static-type  definitions  also  provide  in¬ 
formation  at  compile  time  necessary  for  production  of  efficient 
object  code.  Compile  time  determination  of  types  does  not  pre¬ 
clude  the  inclusion  of  language  structures  for  dynamic  discrim¬ 
ination  among  alternative  record  formats  (see  A7)  cr  among  com¬ 
ponents  of  a  union  type  (see  E6).  Where  the  subtype  or  record 
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structure  cannot  be  deterr.ined  until  run  time,  it  should  still 
be  fully  discriminated  in  the  program  text  so  that  all  the  type 
checks  can  be  completed  at  compile  time. 

A2.  The  language  will  provide  data  types  for  in~ 
tegeTt  real  (floating  point  and  fixed  point)^ 

Boolean^  and  character,  and  as  type  generators , 
will  provide  arrays  (i.e.,  composite  data 
structures  with  indexable  components  of  homo¬ 
geneous  type)  and  records  (i.e.,  composite 
data  structures  with  labeled  components  of 
heterogeneous  type). 

These  are  the  common  data  types  and  type  generators  of 
most  programming  languages  and  object  machines.  They  are  suf¬ 
ficient,  when  used  with  a  data  definition  facility  (see  d6 ,  e6 , 
and  Jl),  to  mechanize  other  desired  types  {e.g.,  complex  or 
vector)  efficiently. 

A2.  The  source  language  will  require  global  (to  a 

scope)  specification  of  the  precision  for  float¬ 
ing-point  arithmetic  and  will  permit  the  global 
precision  to  be  overridden  by  precision  speci¬ 
fication  for  individual  variables.  These  speci¬ 
fications  will  he  interpreted  as  the  maximum 
precision  required  by  the  program  logic  and  the 
minimum  precision  to  be  supported  by  the  object 
code. 


This  is  a  specification  of  what  tne  program  needs,  not 
what  the  hardware  provides.  Machine  independence,  in  the  use 
of  approximate  value  numbers  (usually  with  floating-point 
representation),  can  be  achieved  only  if  the  user  can  place 
constraints  on  the  translator  and  object  machine  without  forc¬ 
ing  a  specific  mechanization  of  the  arithmetic.  Precision 
specifications,  as  the  maximum  required  by  the  object  code, 
provide  all  the  power  and  guarantees  needed  oy  the  programmer, 
without  unnecessarily  constraining  the  object  machine  realization. 
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Precision  specifications  will  not  change  the  type  of  reals  or 
the  set  of  applicable  operations.  Precision  specifications 
apply  to  arithmetic  operations  as  well  as  to  the  data,  and 
therefor':^  should  be  specified  once  for  a  designated  scope.  This 
permits  different  precisions  to  be  used  in  different  parts  of 
a  r  ■  Specification  of  the  precision  will  also  contribute 

to  the  legibility  and  Implementability  of  programs. 

A4.  Fixed-point  numbers  will  be  treated  as  exact 

quantities  which  have  a  range  and  a  fractional 
step  size  determined  by  the  user  at  compile 
time.  Scale- factor  managemsmt  will  be  done 
by  the  compiler. 

Scaled  integers  are  useful  approxim.ations  to  real  numbers 
when  dealing  with  exact  quantity  fractional  values,  when  the 
object  machine  does  not  have  floating-point  hardware,  and  when 
greater  precision  is  required  than  is  available  with  the  float¬ 
ing-point  hardware.  Integers  will  also  be  treated  as  exact 
quantities,  with  a  step  size  equal  to  one. 

AS.  Oharaezer  sets  will  be  treated  as  any  other 
K  name  ration  type. 

.  :  ,:e  any  other  data  type  defined  by  enumeration  (see  Eo), 
it  should  be  possible  to  specify  the  order  of  characters  and 
their  literal  form  to  be  used  in  programs.  These  properties 
of  t  character  set  would  be  unalterable  at  run  tir^e.  The  def- 
i:.'.  tlcn  of  a  character  set  should  reflect  on  the  manner  it  is 
used  within  a  program  and  not  necessarily  on  the  print  repre¬ 
sentation  a  particular  physical  device  associates  with  a  bit 
pattern  at  :-un  time.  In  general,  unless  all  devices  use  the 
same  char  -^r  code,  run-time  translation  between  character 
sets  wi:'  required.  Widely  used  character  sets,  such  as 
I'SASCII  h'DIC  will  be  avallati  In  a  standard  library. 

Note  tha'  a  'ss  to  a  linear  array  filled  with  the  characters 
of  an  alr-hacvt.  A,  and  indexed  by  an  alphabet,  B,  will  con¬ 
vert  strings  of  characters  from  B  to  A. 
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A6. 


The  language  will  require  user  speaifiea- 
tion  of  the  number  of  array  dimensions , 
the  range  of  subscript  values  for  each  ar¬ 
ray  dimension ,  and  the  type  of  each  array 
component.  The  number  of  dimensions,  the 
type,  and  the  lower  subscript  bound  will 
be  determinable  at  compile  time.  The  up¬ 
per  subscript  bound  will  be  determinable 
at  entry  to  the  array  allocation  scope. 

This  is  general  enough  to  permit  both  arrays  which  can 
be  allocated  at  compile  or  load  time  and  arrays  which  can  be 
allocated  at  scope  entry,  but  does  not  permit  dynamic  change 
to  the  size  of  constructed  arrays.  It  is  sufficient  to  permit 
allocation  of  space  pools  which  the  user  can  manage  for  allo¬ 
cation  of  more  com.plex  data  structures,  including  dynar.ic  ar¬ 
rays.  The  range  of  subscript  values  for  any  given  dlm.ensicn 
will  be  a  contiguous  subsequence  of  values  from,  an  enur.eraticn 
type  (including  Integers).  The  preferable  lower  bound  or.  the 
subscript  range  will  be  the  initial  element  of  an  enumeration 
type  or  zero,  because  it  often  contributes  to  pregram  effic¬ 
iency  and  clarity. 

A?.  The  language  will  permit  records  to  have 
alternative  structures,  each  of  which  is 
fixed  at  compile  time.  Tht  name  and  type 
of  each  record  com.ponent  will  be  specified 
by  the  user  at  compile  time. 

This  provides  all  that  is  safe  to  Ui:e  In  CKS-2  and  JOVIAL 
OVERLAY  and  In  FORTRAN’  EQUIVALENCE.  It  rei^lts  hierarchically 
structured  data  of  heterogeneous  type,  per -.its  records  to  have 
alternative  structures,  as  long  as  each  sti-ucture  is  fixed  at 
com.plle  time  and  the  choice  is  fully  discriminated  at  run  tlrie, 
but  it  does  not  permit  arbitrary  references  to  r.emory  or  the 
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dropping  of  type  checking  when  handling  overlayed  structures. 

The  discrimination  condition  will  not  be  restricted  to  a  field 
of  the  record,  but  should  be  any  Boolean  expression. 

B.  OPERATIONS 

B2,  Assignment  and  reference  operations  will 

he  automatically  defined  for  all  data  types 
which  do  not  manage  their  data  storage .  ^She 
assignment  operation  will  permit  any  value  of 
a  given  type  to  be  assigned  to  a  variable,  ar¬ 
ray  or  record  component  of  that  type  or  of  a 
union  type  containing  that  type.  Feference 
will  retrieve  the  last  assigned  value. 

The  user  will  be  able  to  declare  variables  for  all  data 
types.  Variables  are  useful  only  when  there  are  corresponding 
access  and  assignment  operations.  The  user  will  be  permitted 
to  define  assignment  and  access  operations  as  part  of  encapsu¬ 
lated  type  definitions  (see  ES;)-  Otherwise,  they  will  be  au¬ 
tomatically  defined  for  types  which  do  not  manage  the  storage 
for  their  data.  (See  D6  for  further  discussion.) 

B2.  The  source  language  will  have  a  built-in  op¬ 
eration  which  can  be  used  to  compare  any  two 
data  objects  (regardless  of  type)  for  identity. 

Equivalence  is  an  essential  universal  operation  which 
r; ould  not  be  subject  to  restriction  on  its  use.  There  are 
many  useful  equivalence  operations  for  some  types,  and  a  lang- 
uace  definition  cannot  foresee  all  these  for  user-defined  types. 
E:ui  va  i-:.  ce ,  meaning,  logical  identity,  and  not  blt-by-blt  com¬ 
parison  on  the  internal  data  representation,  however,  is  re¬ 
quired  for  all  data  types.  Proper  semantic  interpretation  of 
identity  requires  that  equality  and  identity  be  the  same  for 
atomic  data  (i.e.,  numbers,  characters,  Boolean  values,  and 
types  defined  by  enumeration)  and  that  elements  of  disjoint 
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types  never  be  identical.  Consequently,  its  usefulness  at  run 
time  is  restricted  to  data  of  the  same  type  or  to  types  with 
nonempty  intersections.  For  floating-point  numbers,  identity 
will  be  defined  as  the  same  within  the  specified  (minimum)  pre¬ 
cision. 

BS.  Relational  operations  will  be  autoKati- 
sally  defined  for  numeric  data  and  all 
types  defined  by  enumeration. 

Numbers  and  types  defined  by  enumeration  have  an  obvious 
ordering  which  should  be  available  through  relational  opera¬ 
tions.  All  six  relational  operations  will  be  included.  It 
will  be  possible  to  Inhibit  ordering  definitions  when  unor- 
dei’ed  sets  are  intended. 

B4.  The  built-in  arithmetic  operations  will 
include:  addition^  subtraction,  multi¬ 

plication,  division  (with  a  real  result), 
exponentiation,  integer  division  (with 
integer  or  fixed-point  arguments  and  re¬ 
mainder)  ,  and  negation. 

These  are  the  most  widely  used  num.eric  operations  and  are 
available  as  hardware  operations  in  most  machines.  Floating¬ 
point  operations  will  be  precise  to  at  least  the  specified 
precision . 

B5.  Arithmetic  and  assignment  operations  on 
data  which  are  within  the  range  specifi¬ 
cations  of  the  program  will  never  trun¬ 
cate  the  most  significant  digits  of  a 
numeric  quantity.  Truncation  and  round¬ 
ing  will  always  be  on  the  least-signifi¬ 
cant  digits  and  will  never  be  implicit  for 
integers  and  fixed-point  numbers .  Implicit 
rounding  beyond  the  specified  precision  will 
be  allowei  for  floating-point  numbers. 
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These  requireme’^ts  seen  obvious,  particularly  for  float¬ 
ing-point  numbers,  and  yet  many  of  our  existing  languages  trun¬ 
cate  the  most  significant  mantissa  digits  in  some  mixed  and 
floating-point  operations. 

B6.  The  built-in  Boolean  operations  will  in¬ 
clude  andy  or,  «ot,  and  xor.  Operations 
such  as  and  and  or  on  scalars  will  be 
evaluated  in  short-circuit  mode. 

Short-circuit  mode  as  used  here  is  a  semantic  rather  than 
an  implementation  distinction  and  means  that  and  and  or  are, 
in  fact,  control  operations  which  do  not  evaluate  side  effects 
of  their  second  argument  if  the  value  of  the  first  argument  is 
false  or  true,  respectively.  Short-circuit  evaluation  has  no 
disadvantages  over  the  corresponding  computational  operations, 
sometimes  produces  faster  executing  code  in  languages  where 
the  user  can  rely  on  the  short-circuit  execution,  and  improves 
the  clarity  and  maintainability  of  programs  by  permitting  ex¬ 
pressions  such  as,  i  &  AH']  >x,  which  could  be  erroneous 
v;ere  short-circuit  execution  not  intended.  I!ote  that  the  equiv¬ 
alence  and  nonequivalence  operations  (see  B2)  are  the  same  as 
logical  equivalence  and  exclusive-or ,  respectively. 

F/.  The  source  language  will  permit  scalar 

operations  and  assignment  on  confcrm.able 
arrays  and  will  permit  data  transfers  be¬ 
tween  records  or  arrays  of  identical  logi¬ 
cal  structure . 

Conformabi lity  v;ill  require  exactly  the  sam.e  number  of 
com.ponents  (although  a  scalar  can  be  considered  com.patible 
with  any  array)  and  one-for-one  compatibility  in  type.  Cor¬ 
respondence  will  be  by  position  in  similarly  shaped  arrays. 

In  many  situations,  component-by-component  operations  are  done 
on  array  elements.  In  fact,  a  primary  reason  for  having  ar¬ 
rays  is  to  permit  large  numbers  of  similarly  treated  objects  to 
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have  a  uniform  notation.  Operations  on  large  data  aggregates 
available  directly  In  the  source  language  hide  the  details  of 
the  sequencing  and,  thereby,  simplify  the  program  and  make 
more  optimizations  available.  In  addition,  they  permit  simul¬ 
taneous  execution  on  machines  with  parallel  processing  hard¬ 
ware.  Although  component-by-component  operations  will  be 
available  for  built-in  composite  data  structures  which  are 
used  to  define  application-oriented  structures,  that  capability 
will  not  be  automatically  inherited  by  defined  data  structures. 

A  matrix  might  be  defined  using  an  array,  but  it  will  n*ot  in¬ 
herit  the  array  operations  automatically.  Multiplication  for 
matrices  would,  for  example,  be  unnatural,  confusing,  and  incon¬ 
venient  if  the  product  operator  for  matrices  were  interpreted  as 
a  component-by-component  operation  instead  of  cross  product  of 
corresponding  row  and  column  vectors.  Component-by-component 
operations  also  allow  operations  on  character  strings  repre¬ 
sented  as  vectors  of  characters  and  allow  efficient  Boolean 
vector  operations. 

Transfers  between  arrays  or  records  of  identical  logical 
structure  are  necessary  to  permit  efficient  run  time  conver¬ 
sion  from  one  object  representation  to  another,  as  might  be 
done  when  data  is  packed  to  reduce  peripheral  storage  require¬ 
ments  and  I/O  transfer  times,  but  need  to  be  unpacked  locally 
to  minimize  processing  costs. 

B3.  There  will  he  no  implicit  type  conver- 
sionBt  but  nc  conversion  operation  will 
be  required  when  the  type  of  an  actual 
parameter  is  a  constituent  of  a  union 
type  which  is  the  formal  parameter.  The 
language  will  provide  explicit  conversion 
operations  among  integer ^  fixed-point ^  and 
floating-point  data,  between  the  object 
representation  of  numbers  and  their  repre¬ 
sentations  as  characters ,  and  between  fixed- 
point  scale  factors . 
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Implicit-type  conversions,  which  represent  changes  in  the 
value  of  data  items  without  an  explicit  indicator  in  the  pro- 
greim,  are  not  only  error  prone  but  can  lead  to  unexpected  run 
time  overhead. 

B9.  Explicit  conversion  operations  will  not  be 

required  between  numeric  ranges.  There  will 
be  a  run  time  exception  condition  when  any 
integer  or  fixed-point  value  is  truncated. 

Because  ranges  do  not  form  closed  systems,  range  valida¬ 
tion  is  not  possible  at  compile  time  {e.g.^  I:=I+1  may  be  a 
range  error).  At  best,  the  compiler  might  point  out  likely 
range  errors.  (This  requirement  is  optional  for  hardware 
installations  which  do  not  have  overflow  detection.) 

B20.  The  base  language  will  provide  operations 
allowing  programs  to  interact  with  files, 
channels ,  or  devices,  including  terminals. 

These  operations  will  permit  sending  and 
receiving  both  data  and  control  informa¬ 
tion,  will  enable  programs  to  assign  and 
reassign  I/O  devices  dynamically,  will 
provide  user  control  for  exception  condi¬ 
tions,  and  will  not  be  installation-depen¬ 
dent. 

Whether  the  referenced  "files"  are  real  or  virtual  and 
whether  they  are  hardware  devices,  I/O  channels,  or  logical 
files,  depends  on  the  object  machine  configuration  and  on  the 
details  of  its  operating  system,  if  present.  In  any  program¬ 
ming  system,  I/O  operations  ultimately  reduce  to  sending  or 
receiving  data  or  control  information  to  a  file  or  to  a  de¬ 
vice  controller.  These  can  be  made  accessible  in  an  HOL  in 
an  abstract  form  through  a  small  set  of  generic  I/O  operations 
(like  read  and  write,  with  appropriate  device  and  exception 
parameters).  Note  that  devices  and  files  are  similar  in  many 


flo 


respects  to  types,  so  additional  language  features  may  not  be 
required  to  satisfy  this  requirement.  This  requirement,  in 
conjunction  with  requirement  El,  penults  user  definition  of 
unique  equipment  and  its  associated  I/C  operations  as  data 
types  within  the  syntactic  and  semantic  framework  provided  by 
the  generic  operations. 

Bll.  The  language  will  provide  operations  on 

data  types  defined  as  power  sets  of  enumer¬ 
ation  types  (see  E6),  These  operations  will 
include  union,  intersection,  difference,  com¬ 
plement,  and  an  element  predicate . 

As  with  any  data  type,  power  sets  will  be  useful  only  if 
there  are  operations  which  can  create,  select,  and  Interrogat 
them.  Note  that  this  provides  only  a  very  special  class  of 
sets,  but  one  which  is  very  useful  for  computations  on  sets  o 
indicators,  flags,  and  similar  devices  in  monitoring  and  con¬ 
trol  applications.  More  general  sets,  if  desired,  must  be  ce 
fined,  using  the  type  definition  facilities. 

C.  EXPRESSIONS  AND  PARAMETERS 

Cl.  Side  effects  which  are  dependent  oyi  the 
evaluation  order  among  the  arguments  of 
an  expression  will  be  evaluated  left-to¬ 
ri  ght. 

This  is  a  semantic  restriction  on  the  evaluation  order  c 
arguments  to  expressions.  provides  an  explicit  rule  (t.e. 

le ft-to-right )  for  order  of  argument  evaluation,  but  allows  t 
imp  1. mentations  to  alter  the  actual  order  in  any  way  which  do 
not  change  the  effect.  I’lis  provides  the  user  with  a  simple 
rule  for  determining  the  effects  of  interactions  among  argume 
evaluations  wlthou*"  Imposing  a  strict  rule  on  compilers  which 
are  sophisticated  e..«u  h  to  detect  potential  side-effects  and 
optimize  through  i.jo~'’ering  of  arguments  when  the  evaluation 
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order  does  not  affect  the  result.  Control  operations  {e.g.^ 
conditional  and  Iterative  control  structures),  of  course,  must 
be  exceptions  to  this  general  rule,  since  control  operations 
are.  In  fact,  those  operations  which  specify  the  sequencing 
and  evaluation  rules  for  their  arguments. 

C2.  Which  parte  of  an  expression  constitute  the 
operands  to  each  operation  within  that  ex~ 
pres sion  should  be  obvious  to  the  reader.  » 

There  will  be  few  levels  of  operator  hier~  ^ 

arahy  and  they  will  be  widely  recognized. 

The  operator/operand  structure  of  expressloiTS  must  not  be 
psychologically  ambiguous  (i.e.,  to  guarantee  that  the  parse 
Implemented  by  the  language  Is  the  same  as  Intended  by  the  pro¬ 
grammer  and  understood  by  those  reading  the  program).  This 
kind  of  problem  can  be  minimised  by  having  feu  precedence  levels 
and  parsing  rules,  by  allowing  explicit  parentheses  to  specify 
the  Intended  execution  order,  and  by  requiring  explicit  paren¬ 
theses  when  the  execution  order  is  of  significance  to  the  re¬ 
sult  within  the  same  precedence  level  {e.g.,  X*y*Z  and  X*Y*Z}. 
The  user  will  not  be  able  to  define  new  operator  p’^ecedence 
rules  nor  change  the  precedence  of  existing  operators. 

C3.  Expressions  of  a  given  type  will  be  per¬ 
mitted  anywhere  in  source  programs  where 
both  constants  and  references  to  variables 
of  that  type  are  allowed. 

This  Is  an  example  of  not  imposing  arbitrary  restrlctio.ns 
and  special  case  rules  on  the  user  of  the  source  language. 
Special  mention  Is  made  here  only  because  so  many  languages  do 
restrict  the  foi-m  of  expressions.  FORTRAN,  for  exam.ple,  has 
a  list  of  seven  different  syntactic  forms  for  subscript  ex¬ 
pressions,  Instead  of  allowing  all  form.s  of  arithmetic  expres¬ 
sions  . 
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C4.  Constant  expressions  will  be  allowed  in 
programs  wherever  constants  are  allowed, 
and  constant  expressions  will  be  evalu¬ 
ated  before  run  time. 

The  ability  to  write  constant  expressions  In  programs  has 
proven  valuable  In  languages  with  this  capability,  particularly 
with  regard  to  program  readability  and  In  avoiding  programmer 
error  In  externally  evaluating  and  transcribing  constant  ex¬ 
pressions.  They  are  most  often  used  In  declarations.  There 
Is  no  need,  however,  for  constant  expressions  to  Impose  run 
time  costs  for  their  evaluation.  They  can  be  evaluated  once 
at  compile  time,  or  If  this  Is  Inconvenient  because  of  Incom¬ 
patibilities  between  the  host  and  ob^^ect  machines,  the  compiler 
can  generate  a  code  for  their  evaluation  at  load  time.  In  any 
case,  the  resulting  value  should  be  the  same  (at  least  within 
the  stated  precision),  regardless  of  the  object  machine  (see 
D2).  Allowing  constant  expressions  In  place  of  constants  can 
improve  the  clarity,  correctness,  and  maintainability  of  pro¬ 
grams,  and  does  not  Impose  any  run-time  costs. 

C5.  There  will  be  a  consistent  set  of  rules 
applicable  to  all  parameters,  whether 
they  be  for  procedures ,  types,  exception 
handling,  parallel  processes ,  declarations , 
or  built-in  operations.  There  will  be  no 
special  operations  (c.g.,  array  substruct¬ 
uring)  applicable  only  to  parameters. 

Uniformity  and  consistency  contribute  to  ease  of  learning, 
implementing,  and  using  a  language;  allow  the  user  to  concen¬ 
trate  on  the  programming  task  instead  of  the  language;  and  lead 
to  more  readable,  understandable,  and  predictable  programs. 
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C6 .  Formal  and  actual  parameters  util  always 
agree  in  type.  The  number  of  dimensions 
for  array  parameters  will  be  determinable 
at  compile  time.  The  size  and  subscript 
range  for  array  parameters  need  not  be 
determinable  at  compile  timCt  but  can 
be  passed  as  part  of  the  parameter. 

Type  transfers  hidden  in  procedure  calls  with  incompati~ 
ble  formal  and  actual  parameters,  whether  intentional  or  ac¬ 
cidental,  have  long  been  a  source  of  program  errors  and  of 
programs  which  are  difficult  to  maintain.  On  the  other  hand, 
there  is  no  reason  why  the  subscript  ranges  for  arrays  cannot 
be  passed  as  part  of  the  arguments.  Some  notations  permit 
such  parameters  to  be  implicit  on  the  call  side.  Formal  para¬ 
meters  of  a  union  type  will  be  considered  conformable  to  actual 
parameters  of  any  of  the  component  types. 

C?.  There  will  be  only  four  classes  of  formal 
parameters.  For  data,  there  will  be  those 
which  act  as  constants ,  representing  the 
actual  parameter  value  at  the  time  of  call, 
and  those  which  rename  the  actual  parameter, 
which  must  be  a  variable .  In  addition,  there 
will  be  a  formal  parameter  class  for  specify¬ 
ing  the  control  action  when  exception  cond''- 
tions  occur  and  there  will  be  a  class  for 
procedure  parame  ters . 

The  first  class  of  data  parameter  acts  as  a  constant  within 
the  procedure  body.  Assignments  cannot  be  made  to  these  para¬ 
meters  and  they  cannot  be  changed  during  execution  of  the  pro¬ 
cedure.  Theii’  corresponding  actual  parameter  may  be  any  legal 
expression  of  the  desired  type  and  will  be  evaluated  once  at 
the  time  of  call.  The  second  class  of  data  parameter  renames 


the  actual  parameter  which  must  be  a  variable.  The  address  of 
the  actual  parameter  variaole  will  be  determined  by  (or  at) 
the  time  of  call  and  will  be  unalterable  during  execution  of 
the  procedure.  Assignment  (or  rei*.rence)  to  the  formal  para¬ 
meter  name  will  assign  (or  access)  the  variable  which  is  the 
actual  parameter.  These  are  the  only  two  widely  used  para¬ 
meter-passing  mechanisms  for  data.  The  many  alternatives  (at 
least  10  have  been  suggested)  add  complexity  and  cost  to  a 
language  without  sufficiently  increasing  its  clarity  or  poVer. 

A  language  with  exception-handling  capability  must  have  a  way 
to  pass  control  and  related  data  through  procedure-call  inter¬ 
faces.  Exception-handling  control  parameters  will  be  specified 
on  the  call  side  only  when  needed.  Actual  procedure  parameters 
will  be  restricted  to  those  of  similar  (explicit  or  implicit) 
specification  parts. 

C8.  Specification  of  the  type,  range ^  precision^ 
dimension y  scaley  and  format  of  parameters 
will  be  optional  on  the  formal  side  (i.e,, 
in  the  procedure  declaration) .  None  of  them 
will  be  alterable  at  run  time. 

Optional  formal  parameter  specification  permits  the  writ¬ 
ing  of  generic  procedures  which  are  instantiated  at  compile 
time  by  the  characteristics  of  their  actual  parameters.  It 
eliminates  the  need  for  compile  tim.e  type  parameters.  This 
generic  procedure  capability,  for  example,  allows  the  defini¬ 
tion  of  stacks  and  queues  and  their  associated  operations  on 
data  of  any  given  type,  without  knowing  the  data  type  when  the 
operations  are  defined.  This  does  not  conflict  with  the  re¬ 
quirement  for  complle-tlme-determinable  type  determination  (Al), 
because  the  language  permits  union  types  (see  E6)  and  compile 
time  evaluation  of  constant  expressions  (see  C^),  Including 
type  testing  expressions. 
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C9.  There  will  be  provision  for  variable 

numbers  of  arguments ^  but  in  such  oases 
all  but  a  constant  number  of  them  must 
be  of  the  same  type.  Whether  a  routine 
can  have  a  variable  number  of  arguments 
must  be  determinable  from  its  descrip¬ 
tion  ^  and  the  number  of  arguments  for 
any  call  will  be  determinable  at  com¬ 
pile  time. 

There  are  many  useful  purposes  for  procedures  with  vari¬ 
able  numbers  of  arguments.  These  include  intrinsic  functions 
such  as  print,  generalizations  of  operations  which  are  both 
commutative  and  associative,  such  as  max  and  min,  and  repeti¬ 
tive  application  of  the  same  binary  operation  such  as  the  Lisp 
list  operation.  The  use  of  operations  with  variable  numbers 
of  arguments  need  not  and  will  not  cause  I’elaxation  of  any 
compile-time  checks,  require  use  of  multiple- entry  orccedures, 
allow  the  number  of  actual  parameters  to  vary  at  run  time,  or 
require  special  calling  mechanisms.  If  the  parameters  which 
can  vary  are  limited  to  a  program-specified  type  treated  as  any 
other  argument  on  the  call  side  and  as  elements  of  an  array 
within  the  procedure  definition,  full  type  checking  can  be  dene 
at  compile  time.  There  v'ill  be  no  prshibitlon  on  writing  a 
special  case  of  a  procedure  for  a  particular  number  of  argu¬ 
ments  , 

D.  VARIABLES,  LITERALS,  AND  CONSTANTS 

Dl,  The  user  will  have  the  ability  to  associate 
constant  values  of  any  type  with  identi¬ 
fiers. 

The  use  of  identifiers  to  represent  constant  values  has 
often  made  programs  more  readable,  more  easily  modifiable,  and 
less  prone  to  error  when  the  value  of  a  constant  is  changed. 
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Associating  constant  values  with  an  Identifier  is  preferable 
to  assigning  the  value  to  a  variable,  because  it  Is  then  clearly 
marked  in  the  program  as  a  constant,  can  be  automatically  checked 
for  unintentional  changes,  and  often  can  have  a  more  efficient 
object  representation. 

D2.  The  language  will  provide  a  cyntaz  and  a  con¬ 
sistent  interpretation  for  constants  of  built- 
in  data  types.  Numeric  constants  will  have  the 
same  value  (within  the  specified  precision )  in 
both  programs  and  data  (input  or  output). 

Constants  are  needed  for  all  atomic  data  types  and  should 
be  provided  as  part  of  the  language  definition  for  built-in 
types.  Regardless  of  the  source  of  the  data  and  of  the’  object 
machine,  the  value  of  constants  should  be  the  same.  For  inte¬ 
gers,  it  should  be  exact,  and  for  reals  it  should  be  the  same, 
within  the  specified  precision.  Compiler  writers,  however, 
would  disagree.  They  object  to  this  requirement  on  twc  grounds: 
that  it  is  too  costly  if  the  host  and  object  machines  a^e  dif¬ 
ferent,  and  that  it  is  unnecessary  if  they  are  the  same.  In 
fact,  all  costs  are  at  compile  time  and  must  be  Insignificant 
compared  to  the  life-time  costs  resulting  from  object  codes 
containing  the  wrong  constant  values.  As  for  being  unr.ecess  ary , 
there  have  been  all  too  many  cases  of  different  values  fn:m. 
program  and  data  literals  on  the  same  machine  because  the  com¬ 
pile  time  and  run  time  conversion  packages  were  different  and 
imprecise. 

D3.  The  language  will  permit  the  user  to  specify 
the  initial  values  of  individual  variables 
as  part  of  their  declaration .  Such  variables 
will  be  initialized  at  the  time  of  their  appar¬ 
ent  allocation  li.e.,  at  entry  to  allocation 
scope).  There  will  be  no  default  initial  values. 
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The  ability  to  initialize  variables  at  the  time  of  their 
allocation  will  contribute  to  frograai  clarity,  but  a  requii^- 
ment  to  do  so  would  be  an  arbitrary  and  sometimes  costly  de¬ 
cision.  Default  initial  values,  on  the  other  hand,  contribute 
to  neither  program  clarity  nor  correctness  and  can  be  even 
more  costly  at  run  time.  It  is  usually^  a  programming  error  if 
a  variable  is  accessed  before  it  is  initialize<i.  It  is  desir¬ 
able  that  the  translator  give  a  warning  when  a  path  between 
the  declaration  and  use  of  a  variable  omits  initialization. 
Whether  a  variable  will  be  assigned  is,  in  general,  an  unsolv- 
able  problem,  but  it  is  sometimes  determinable  whether  assign¬ 
ments  occur  on  potential  paths.  In  the  case  of  arrays,  it  is 
possible  at  compile  time  only  to  determine  that  some  component 
(but  not  necessarily  which)  have  been  initialized.  There  will 
be  provision  (at  user  option)  for  run  time  testing  for  initial 
zation. 

D4.  The  aourae  language  wilt  require  its  users 
to  specify  individually  the  range  of  all 
numeric  variables  and  the  step  size  for 
fixed-point  variables .  The  range  speci¬ 
fications  will  be  interpreted  as  the  maxi¬ 
mal  range  of  values  which  will  be  assigned 
to  a  variable  and  the  minimal  range  which 
must  be  supported  by  the  object  code.  Range 
and  step-size  specifications  will  not  be  in~ 
terpreted  as  defining  new  types. 

Range  specifications  are  a  special  form  of  assertion. 

They  aid  in  understanding  and  determining  the  correctness  of 
programs.  Ttiey  can  also  be  used  as  additional  information  ty 
the  compiler  in  deciding  what  storage  and  allocation  to  use 
{e.g.j  half  words  might  be  more  efficient  fox’  integers  in  the 
range  0  to  1000).  Range  specifications  also  offer  the  oppor¬ 
tunity  for  the  translator  to  insert  range  tests  automatically 
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for  run  time  or  debug  time  validation  of  the  program  logic. 

With  the  ranges  of  variables  specified  in  the  program,  it  be¬ 
comes  possible  to  perform  many  subscript  bounds  checks  at  com¬ 
pile  time.  These  bounds  checks,  however,  can  be  only  as  valid 
as  the  range  specifications,  which  Ccinnot,  in  general,  be  vali¬ 
dated  at  compile  time.  Range  specifications  on  approximate 
valued  variables  (usually  with  floating-point  implementation) 
also  offer  the  possibility  of  their  implementation  using  fixed- 
point  hardware . 

DS,  The  range  of  values  tdhioh  can  he  associated 
with  a  variable ^  array ,  or  record  component 
will  be  any  built-in  type,  any  defined  type, 
or  a  contiguous  subsequence  of  any  enumera¬ 
tion  type. 

There  should  not  be  any  arbitrary  restrictions  on  tne 
structure  of  data.  This  permits  arrays  to  be  components  of 
records  or  arrays  and  permits  records  to  be  components  of  ar¬ 
rays. 

D6 .  The  language  will  provide  a  pointer  mech¬ 
anism  which  can  be  used  to  build  data  with 
shared  and/or  recursive  substructure.  The 
pointer  property  will  only  affect  the  use 
of  variables  (including  array  and  record 
components )  of  some  data  types.  Pointer 
variables  will  he  as  safe  in  their  use  as 
are  any  other  variables . 

Depending  on  the  data  type,  variables  of  that  type  will 
hold  values  which  either  can  be  shared  or  must  be  unique  to 
that  variable.  Assignment  to  a  variable  of  a  shared  value  type 
will  mean  that  the  variable's  name  is  to  act  as  an  additional 
label  (or  reference)  on  the  datum  being  assigned.  Assignment 
to  a  variable  of  a  unique  value  type  will  mean  that  the  vari¬ 
able's  name  is  to  label  a  copy  of  the  object  beinr  assigned. 
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For  data  without  alterable  component  values,  there  Is  no  func¬ 
tional  difference  between  reference  to  multiple  copies  and  mul¬ 
tiple  references  to  a  single  copy.  Consequently,  whether  values 
are  shared  or  copies  Is  meaningful  only  for  composite  types  and 
for  arrays  and  records  with  composite  components.  Whether  a 
composite  type  has  shared  or  copied  values  will  be  specified  as 
part  of  the  type  definition.  The  use  of  pointers  (i.c.,  shared 
values)  will  be  kept  safe  by  prohibiting  variables  from  holding 
values  whose  allocation  scopes  are  narrower  than  that  of  the 
variable.  Such  a  restriction  Is  easily  enforced  at  compile 
time  using  hierarchical  scope  rules,  providing  there  Is  no  way 
to  dynamically  create  new  Instances  of  the  data  type.  In  the 
latter  case,  the  dynamically  created  data  can  be  allocated  with 
full  safety,  using  a  (user  or  ilbrary-definedj  space  pool  which 
is  either  local  (t.e.,  own)  or  global  to  the  type  definition. 

If  variables  of  a  type  are  not  shared,  dynamic  storage  alloca¬ 
tion  will  be  required  for  assignment  unless  their  size  Is  con¬ 
stant  and  known  at  the  time  of  variable  allocation.  Thus, 
copied  variables  will  be  permitted  only  for  types  (a)  whos 
data  have  a  structure  and  size  which  Is  constant  In  the  type 
definition,  or  (b)  which  manage  the  storage  for  their  data  as 
part  of  the  type  definition.  Because  shared  values  are  often 
less  expensive  at  run  time  than  copied  values  and  are  subject 
to  fewer  restrictions,  the  specification  of  copied  values  will 
be  explicit  in  programs  (this  is  similar  to  the  ALG0L-6C  Issue 
concerning  the  explicit  specification  of  value  (t.c.,  copied) 
and  name  {i.e.t  shared).  The  need  for  pointers  is  obvious  ir. 
building  data  structures  with  shared  or  recursive  substructures, 
such  as,  directed  graphs,  stacks,  queues,  and  list  structures. 
Providing  pointers  as  absolute  address  types,  however,  produces 
gaps  In  the  type  checking  and  scope  mechanisns.  Type-  and  ac¬ 
cess-restricted  pointers  will  provide  the  power  of  general 
pointers,  without  their  undesirable  characteristics. 
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E. 


DEFINITION  FACILITIES 


El.  The  user  of  the  language  will  be  able  to 

define  new  data  ^vpea  and  operationa  with¬ 
in  programs . 

The  number  of  specialized  capabilities  needed  for  a  com¬ 
mon  language  is  large  and  diverse.  In  maiiy  cases,  thfe're  is  no 
consensus  as  to  the  form  these  capabilities  should  take  in  a 
programming  language.  The  operational  requirements  dictating 
specific  specialized  language  capabilities  are  volatile,  and 
future  needs  cannot  always  be  foreseen.  No  leinguage  can  make 
available  all  the  features  useful  to  the  broad  spectrxim  of  mil¬ 
itary  applications,  anticipate  future  applications  and  require¬ 
ments,  or  even  provide  a  universally  "best"  capability  in  sup¬ 
port  of  a  single  pppllcaLiun  area.  A  common  language  needs 
capability  for  growth.  It  should  contain  all  the  power  neces¬ 
sary  to  satisfy  all  the  applications  and  the  ability  to  spe¬ 
cialize  th.it  power  to  the  particular  application  task.  A  lang¬ 
uage  with  defining  facilities  for  data  and  operations  often 
makes  it  possible  to  add  new  application-oriented  structures 
and  to  use  new  programming  techniques  and  mechanisms  through 
descriptions  written  entirely  within  the  language.  Definitions 
will  have  the  appearance  and  costs  of  features  built  into  the 
language  while  they  are  actually  catalogued  as  application  pack 
ages.  The  operation  definition  facility  will  include  the  abil¬ 
ity  to  define  I'ew  infix  and  prefix  operator’s  (but  see  H2  for 
restrictions).  No  programming  language  can  be  all  things  to 
all  people,  but  a  language  with  data  and  operation  definition 
facilities  can  be  adapted  to  meet  changing  requirements  in  a 
variety  of  areas. 

The  ability  to  define  data  and  operations  is  well  within 
the  state  of  the  ai’t .  Operation  definition  facilities  in  the 
form  of  subroutines  have  been  available  in  all  general-purpose 
programming  languages  since  at  least  the  time  of  early  FORTRANs 
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Data  definition  facilities  have  been  available  In  a  variety 
of  programming  languages  for  almost  10  years  and  reached  their 
peak  with  more  than  30  extensible  languages  In  1968  and  shortly 
thereafter  (Ref.  A  trend  toward  more  abstract  and  less 

machine-oriented  data  specification  mechanisms  has  appeared 
more  recently  In  PASCAL  (Ref.  5).  Data  type  definitions,  with 
operations  and  data  defined  together,  are  used  In  several  lang¬ 
uages,  Including  SIMULA-67  (Ref.  6).  On  the  other  hand,  there 
is  currently  .nuch  ferment  as  to  what  Is  the  proper  function  and 
form  of  data  type  definitions. 

E2.  The  use  of  defined  types  will  be  indis¬ 
tinguishable  from  built-in  types. 

Whether  a  type  Is  bullt-ln  or  defined  within  the  base  will 
not  be  determinable  from  Its  syntactic  and  semantic  properties. 
There  will  be  no  ad  hoc  special  cases  or  Inconsistent  rules  to 
Interfere  with  and  complicate  learning,  using,  and  Implementing 
the  language.  If  bullt-ln  features  and  user-defined  data  struc¬ 
tures  and  operations  are  treated  In  the  same  way  throughout  the 
language,  so  that  the  base  language,  standard  application  li¬ 
braries,  and  application  programs  are  treated  In  a  uniform  man¬ 
ner  by  the  user  and  by  the  translator,  then  these  distinctions 
will  grow  dim,  to  everyone’s  advantage.  To  achieve  these  goals, 
full  encapsulation  capabilities  are  needed,  as  well  as  ways  to 
specify  special  selection,  printing,  and  storage  management 
policies  for  underlying  representations.  When  the  language 
contains  all  tne  essential  power,  when  few  can  tell  the  dif¬ 
ference  between  the  base  language  and  library  definition 3,  and 
when  the  Introduction  of  new  data  types  and  routines  does  not 
have  an  Impact  on  the  compiler  and  the  language  standards,  then 
there  Is  little  Incentive  to  proliferate  languages.  Similarly, 
If  type  definitions  are  processed  entirely  at  compile  time  and 
the  language  allows  full  program  specification  of  the  Internal 
representation,  there  need  be  no  penalty  to  run  time  efficiency 
for  using  defined  types. 
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EZ.  Each  program  component  wilt  be  defined 
in  the  base  language ,  in  a  library^  or 
in  the  program.  There  will  be  no  de¬ 
fault  declarations . 

As  programmers,  we  should  not  expect  the  trcinslator  to 
write  our  programs  for  us  (at  least  in  the  immediate  future). 

If  we  somehow  know  that  the  translator's  default  convertion  is 
compatible  with  our  needs  for  the  case  at  hand,  we  should  still 
document  the  choice  so  others  can  understand  and  maintain  our 
programs.  Neither  should  we  be  able  to  delay  definitions  (pos¬ 
sibly  forget  them)  until  they  cause  trouble  in  the  operational 
system.  This  is  a  special  case  of  requirement  II. 

E4.  The  user  will  be  akle^  within  the  source 
language ,  to  extend  existing  operators 
to  new  d'-ta  types. 

When  an  operation  is  an  abstraction  of  an  existing  opera¬ 
tion  for  a  new  type  or  is  a  generalization  of  an  existing  op¬ 
eration,  it  is  inconvenient,  confusing,  and  misleading  to  use 
any  but  the  existing  operator  symbol  cr  function  name.  The 
translator  will  not  assume  that  commutativity  of  built-in  op¬ 
erations  is  preserved  by  extensions,  and  any  assumptions  about 
the  associativity  of  built-in  or  extended  operations  will  be 
ignored  by  the  translator  when  explicit  parentheses  are  pro¬ 
vided  in  an  expression. 

ES.  Type  definitions  in  the  source  language  will 
permit  definition  o~  both  the  class  of  data 
objects  comprising  the  type  and  the  set  of 
operations  applicable  to  that  class.  A  de¬ 
fined  type  will  not  automatically  inherit 
the  operations  of  the  data  with  which  it  is 
represented. 


Types  define  abstract  data  objects  with  special  properties. 
The  data  objects  are  given  a  representation  in  terms  of  exis¬ 
ting  data  structures,  but  they  are  of  little  value  until  opera¬ 
tions  are  available  to  take  advantage  of  their  special  proper¬ 
ties.  When  one  obtains  access  to  a  type,  he  needs  its  opera¬ 
tions  as  well  as  its  data.  Numeric  data  is  needed  in  many  ap- 
plications,  but  is  of  little  value  without  arithmetic  opera¬ 
tions.  The  definable  operations  will  include  constructors,  se¬ 
lectors,  predicates,  and  type  conversions. 

E6.  The  data  objects  comprising  a  defined  type 
will  be  definable  by  enumeration  of  their 
literal  names,  as  Cartesian  products  of  ex¬ 
isting  types  (i.e.,  as  array  and  record 
classes) ,  by  discriminated  union  (i.e.,  as 
the  union  of  disjoint  types)  and  as  the 
power  set  of  an  enumeration  type.  These 
definitions  will  be  processed  entirely  at 
compile  time. 

The  above  list  comprises  a  currently  known  set  of  useful 
definitional  mechanisms  for  data  types  which  do  not  require 
run  time  support,  as  do  garbage  collection  and  dynamic  storage 
allocation.  In  conjunction  with  pointers  (see  D6),  they  pro¬ 
vide  many  of  the  mechanisms  necessary  to  define  recursive  data 
structures,  and  efficient  sparse  data  structures. 

E7,  Type  definitions  by  free  union  (i.e.,  union  of 
non-dis joint  types)  and  subsetting  are  not 
desired. 

Free  union  adds  no  new  power  not  provided  by  discriminated 
union,  but  does  require  giving  up  the  security  of  types  in  re¬ 
turn  for  programmer  freedom.  Range  rnd  subset  specifications 
on  ariables  are  useful  documentation  and  debugging  aids,  but 
will  not  be  construed  as  types.  Subsets  do  not  introduce  new 
properties  or  operations  not  available  to  the  superset  and 
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often  do  not  form  a  closed  system  under  the  superset  operations. 
Callke  types,  membership  in  subsets  can  be  determined  only  at 
run  time. 

E8.  Whf.n  defining  a  type^  the  ueer  will  be  able 
to  specify  the  initialization  and  finaliza¬ 
tion  procedures  for  the  type  and  the  actions 
to  be  taken  at  the  time  of  allocation  and 
deallocation  of  variables  of  that  type. 

It  is  often  necessary  to  do  bookkeeping  or  to  talte  other 
special  action  when  variables  of  a  given  type  are  allocated  or 
deallocated.  The  language  will  not  limit  the  class  of  definable 
types  by  withholding  the  ability  to  define  those  actions.  Init¬ 
ialization  might  take  place  once  when  the  type  is  allocated 
(t.e.,  in  its  allocation  scope)  and  would  be  used  to  set  up  the 
procedures  and  initialize  the  variables  which  are  local  to  the 
type  definition.  These  operations  will  be  definable  in  the  en¬ 
capsulation  housing  the  rest  of  the  type  definition. 

F.  SCOPES  AND  LIBRARIES 

FI.  The  language  will  allow  the  user  to  dis¬ 
tinguish  between  scope  of  allocation  and 
scope  of  access. 

The  scope  of  allocation  or  lifetime  of  a  program  structure 
is  that  region  of  the  program  for  which  the  object  representa¬ 
tion  of  the  structure  should  be  present.  The  allocation  scope 
defines  the  program  scope  for  which  own  variables  of  the  struc¬ 
ture  must  be  maintained  and  identifies  the  time  for  initializa¬ 
tion  of  the  structure.  The  access  scope  defines  the  regions  of 
the  program  in  which  the  allocated  structure  is  accessible  to 
the  program  and  will  never  be  wider  than  the  allocation  scope. 

In  some  cases,  the  user  may  desire  that  each  use  of  a  defined 
program  structure  be  Independent  (i.e.,  the  allocation  and 
accessing  scopes  would  be  Identical).  In  other  cases,  the 
various  accessing  scopes  might  share  a  common  allocation  of  the 
structure. 
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F2.  The  ability  to  limit  access  to  separately 
defined  structures  will  be  available  both 
where  the  structure  is  defined  and  where 
it  is  used.  It  will  be  possible  to  as¬ 
sociate  new  local  names  with  separately 
defined  program  components . 

Limited  access  specified  in  a  type  definition  is  necessary 
to  guarantee  that  changes  to  data  representations  and  to  man¬ 
agement  routines  which  purportedly  do  not  affect  the  calling 
programs,  are.  In  fact,  safe.  By  rigorously  controlling  the 
set  of  operations  applicable  to  a  defined  type,  the  type  defi¬ 
nition  guarantees  that  no  external  use  of  the  type  can  acci¬ 
dentally  or  intentionally  use  hidden  nonessential  properties 
of  the  type.  Renaming  separately  defined  programming  compo¬ 
nents  is  necessary  to  avoid  naming  conflicts  when  they  are 
used . 

Limited  access  on  the  call  side  provides  a  high  degree  of 
safety  and  eliminates  nonessential  naming  conflicts  without 
limiting  the  degree  of  accessibility  which  can  be  built  into 
programs.  The  alternative  notion,  that  all  declarations  which 
are  external  to  a  program  segment  should  have  the  same  scope, 
is  Inconvenient  and  costly  in  creating  large  systems  which  are 
composed  of  many  subsystems,  because  it  forces  global  access 
scopes  £tnd  the  attendant  naming  conflicts  on  subsystems  not 
using  the  defined  items. 

F3.  The  scope  of  identifiers  will  be  wholly 
determined  at  compile  time. 

Identifiers  will  ’'e  declared  at  the  beginning  of  their 
scope,  and  multiple  use  of  variable  names  will  not  be  allowed 
in  the  same  scope.  Except  as  otherwise  explicitly  specified 
in  programs,  access  scopes  will  be  lexically  embedded,  with  the 
most  local  definition  applying  when  the  same  identifer  appears 
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at  several  levels.  The  language  will  use  the  above  lexically 
embedded  scope  rules  for  declarations  and  other  definitions  of 
identifiers  to  make  them  easy  to  recognize  and  to  avoid  errors 
and  ambiguities  from  multiple  use  of  identifiers  in  a  single 
scope. 

F4.  A  variety  of  application~oriented  data  and 
operations  will  be  available  in  libraries 
and  easily  accessible  in  the  language . 

A  simple  base  alone  is  not  sufficient  for  a  common  lang¬ 
uage.  Even  though,  in  theory,  such  a  language  provides  the 
necessary  power  and  tne  capability  for  specialization  to  par¬ 
ticular  applications,  the  users  of  the  language  cannot  be  ex¬ 
pected  to  develop  and  support  common  libraries  under  individual 
projects.  There  will  be  broad  support  for  libraries  common  to 
users  of  well-recognized  application  areas.  Application  li¬ 
braries  will  be  developed  as  early  as  possible. 

Fb.  Program  components  not  defined  within  the 
current  program  and  not  in  the  base  lang¬ 
uage  will  be  maintained  in  libraries  ac¬ 
cessible  at  compile  time.  The  libraries 
will  be  capable  of  holding  anything  de¬ 
finable  in  the  language  and  will  not  ex¬ 
clude  routines  whose  bodies  are  written 
in  other  source  languages . 

The  usefulness  of  a  language  derives  primarily  from  the 
existence  and  accessibility  of  specialized  application-oriented 
data  and  operations.  V/hether  a  library  should  contain  source 
or  object  codes  is  a  question  of  implementation  efficiency  and 
should  not  be  specified  in  the  definition  of  the  source  lang¬ 
uage,  but  the  source  language  description  will  always  be  avail¬ 
able.  It  should  be  remembered,  however,  that  interfaces  can¬ 
not  be  validated  at  program  assembly  time  without  some  equiv¬ 
alent  of  their  source  language  interface  specifications,  that 
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object  modules  are  machine-dependent  and,  therefore,  not  port¬ 
able,  that  source  code  is  often  more  compact  than  object  code, 
and  that  compilers  for  simple  languages  can  sometimes  compile 
faster  than  a  loader  can  load  from  relocatable  object  programs. 
Library  routines  written  in  other  languages  will  not  be  pro¬ 
hibited,  provided  the  foreign  routine  has  object  codes  compati¬ 
ble  with  the  calling  mechanisms  used  in  the  Common  HOL  and  pro¬ 
viding  sufficient  header  Information  (e.g.y  parameter  types, 
form,  and  number)  is  given  with  the  routine  in  Common  HOL  form 
to  permit  the  required  compile  time  checks  at  the  interface. 

F6.  Libraries  and  Compools  will  be  indistin¬ 
guishable.  They  will  be  capable  of  holding 
anything  definable  in  the  language y  and  it 
will  be  possible  to  associate  them  with  any 
level  of  programming  activity  from  systemsy 
through  projects,  to  individual  programs . 

There  will  be  many  specialized  compools  or 
libraries ,  any  user-specified  subset  of  which 
is  immediately  accessible  from  a  given  pro¬ 
gram. 

Compools  have  proven  very  useful  in  organizing  and  con¬ 
trolling  shared  data  structures  and  shared  routines.  A  simi¬ 
lar  mechanism  will  be  available  to  manage  and  control  access  to 
related  library  definitions. 

F7 .  The  source  language  will  contain  standard 
machine-independent  interfaces  to  machine- 
dependent  capabilities,  including  peripheral 
equipment  and  special  hardware. 

The  convenience,  ease  of  use,  and  savings  in  production 
and  maintenance  costs  resulting  from  using  high-order  languages 
come  from  being  able  to  use  specialized  capabilities  without 
building  them  from  scratch.  Thus,  it  is  essential  that  high- 
level  capabilities  be  supplied  with  the  language.  The  idea  is 


not  to  provide  all  the  many  special  cases  in  the  language,  but 
to  provide  a  few  general  cases  which  will  cover  the  special 
cases . 

There  is  currently  little  agreement  on  standard  operating 
system,  I/O,  or  file  system  interfaces.  This  does  not  preclude 
support  of  one  or  more  forms  for  the  near  term.  For  the  pres¬ 
ent,  the  important  thing  is  that  one  be  chosen  and  made  avail¬ 
able  as  a  standard  supported  library  definition  which  the  user 
can  use  with  confidence. 

G.  CONTROL  STRUCTURES 

Gl.  The  language  will  provide  structured  con¬ 
trol  mechanisms  for  sequential,  conditional , 
iterative ,  and  recursive  control.  It  will 
also  provide  control  si-ructures  for  (pseudo) 
parallel  processing,  exception  handling,  and 
asynchronous  interrupt  handling . 

These  mechanisms,  hopefully,  provide  a  spanning  set  of 
control  structures.  The  most  appropriate  operations  in  sev¬ 
eral  of  these  areas  is  an  open  question.  For  the  present,  the 
choice  will  be  a  spanning  set  of  composable  control  primitives, 
each  of  which  is  easily  mapped  onto  object  machines  and  which 
does  not  Impose  run  time  charges  when  it  is  not  used.  The  ob¬ 
ject  machine  determines  whether  parallel  processing  is  real 
(i.e.,  by  multiprocessing)  or  is  synthesized  on  a  single  se¬ 
quential  processor,  but  if  programs  are  written  as  if  there  is 
true  parallel  processing  (and  no  assumption  about  the  relative 
speeds  of  the  processors)  then  the  same  results  will  be  ob¬ 
tained  Independent  of  the  object  environment. 

It  is  desirable  that  the  number  of  primitive  control  struc¬ 
tures  in  the  language  be  minimized,  not  by  reducing  the  power 
of  the  language,  but  by  selecting  a  small  set  of  composable  prim 
itives  which  can  be  used  to  easily  build  other  desired  control 
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mechanisms  within  programs.  This  means  that  the  capabilities 
of  control  mechanisms  must  be  separable,  so  that  the  user  need 
not  pay  either  program  clarity  or  implementation  costs  for  un¬ 
desired  specialized  capabilities.  By  these  criteria,  the  ALGOL- 
60  for  would  be  undesirable  because  it  imposes  the  use  of  a  loop 
control  variable,  requires  that  there  be  a  single  terminal  con¬ 
dition,  and  that  the  condition  be  tested  before  each  iteration. 
Consequently,  for  cannot  be  composed  to  build  other  useful  it¬ 
erative  control  structures  (e.g.,  FORTRAN  do).  The  ability  to 
compose  control  structures  does  not  imply  an  ability  to  define 
new  control  operations,  and  such  an  ability  is  in  conflict  with 
the  limited  parameter- passing  mechanisms  of  C7. 

G2.  The  source  language  will  provide  a  go¬ 
to  operation  applicable  to  progran 
labels  within  its  most  local  scope  of 
definition. 

The  go  to  is  a  machine-level  capability  which  is  still 
needed  to  fill  in  any  gaps  that  might  remain  in  the  choice  of 
structured  control  primitives,  to  provide  compatibility  for 
transliterating  programs  written  in  older  languages,  and  be¬ 
cause  of  the  wide  familiarity  of  current  practitioners  with  its 
use.  The  language  should  not,  however,  impose  unnecessary 
costs  for  its  presence.  The  go  to  will  be  limited  to  explicitly 
specified  program  labels  at  the  same  scope  level.  Neither 
should  the  language  provide  specialized  facilities  which  en¬ 
courage  its  use  in  dangerous  and  confusing  ways.  Switches, 
designational  expressions,  label  variables,  label  parameters 
and  numeric  labels  are  not  desired.  Switches  here  i*efer  to  the 
unrestricted  switches  which  are  generalizations  of  the  go  to 
and  do  not  refer  to  case  statements  which  are  a  general  form 
for  conditionals  (see  G3)-  This  requirem.ent  should  not  be  in¬ 
terpreted  to  conflict  with  the  specialized  form  of  control 
ci’ansfer  provided  by  the  exception-handling  control  structure 
of  G7. 
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G3.  The  conditional  control  etructurea  will 
be  fully  partitioned  and  will  permit  se¬ 
lection  among  alternative  computatione 
baaed  on  the  value  of  a  Boolean  expreeaion, 
on  the  subtype  of  a  value  from  a  discrimi¬ 
nated  union,  or  on  a  computed  choice  among 
labeled  alternatives . 

The  conditional  control  operations  will  be  fully  parti¬ 
tioned  (e.g.,  an  else  clause  must  follow  each  if  then)  so  the 
choice  is  clear  and  explicit  in  each  case.  There  will  be  some 
general  form  of  conditional  which  allows  an  arbitrary  computa¬ 
tion  to  determine  the  selected  situation  ie.g.,  Zahn's  device 
(Ref.  7)  provides  a  good  solution  to  the  general  problem]. 

Special  mechanisms  are  also  needed  for  the  more  common  cases  of 
the  Boolean  expression  ie.g.,  if  then  else)  and  for  value  or 
type  discrimination  (e.g.,  case  on  one  of  a  set  of  values  or 
subtype  of  a  union). 

£74.  The  iterative  control  structure  will  per¬ 
mit  the  termination  condition  to  appear 
anywhere  in  the  loop,  will  require  con¬ 
trol  variables  to  be  local  to  the  itera¬ 
tive  control,  will  allow  entry  only  at  the 
head  of  the  loop,  and  will  not  impose  ex¬ 
cessive  overhead  in  clarity  or  run  time  ex¬ 
ecution  coats  for  common  special  case  termi¬ 
nation  conditions  (e.g.,  fixed  number  of  it¬ 
erations  or  elements  of  an  array  exhausted) . 

In  its  most  general  form,  a  programmed  loop  is  executed 
repetitively  until  some  computed  predicate  becomes  true.  There 
may  be  more  than  one  terminating  predicate,  and  they  might  ap¬ 
pear  anywhere  in  the  loop.  Specialized  control  structures  ie.g.. 
While  do)  have  been  used  for  the  common  situation  in  which  the 
termination  condition  precedes  each  iteration.  The  most  common 
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case  is  termination  after  a  fixed  number  of  iterations  and  a 
specialized  control  structure  should  be  provided  for  that  pur¬ 
pose  (e.g.t  FORTRAN  do  or  ALGOL-60  for).  A  problem  which  arlrs 
in  many  programming  languages  is  that  loop  control  variables 
are  global  to  the  iterative  control,  and,  thus,  will  have  a 
value  after  loop  termination,  but  that  value  is  usually  an  at- 
cident  of  the  implementation.  Specifying  the  aeaning  of  con¬ 
trol  variables  after  loop  termination  in  the  language  defini¬ 
tion  resolves  the  ambiguity,  but  must  t?  an  arbitrary  decisim 
which  will  not  aid  program  clarity  or  correctness,  and  may  ir^ 
terfere  with  the  generation  of  efficient  object  codes.  Loop 
control  variables  are,  by  definition,  variables  used  to  convrrl 
the  repetitive  execution  of  a  programmed  loop,  and,  as  such, 
will  be  local  to  the  loop  body.  At  loop  termination,  it  will 
be  possible  to  pass  their  value  (or  any  other  computed  value) 
out  of  the  loop,  conveniently  and  efficiently. 

G5.  Recursive  as  well  as  nonrecursive  routines 
will  be  available  in  the  source  language, 

Jt  will  not  be  possible  to  define  proced~ 
ures  within  the  body  of  a  recursive  pro¬ 
cedure  . 

Recursion  is  desirable  in  many  applications  because  it 
contributes  directly  to  their  elegance  and  clarity  and  simpli¬ 
fies  proof  procedures.  Indirectly,  it  contributes  to  the  re¬ 
liability  and  maintainability  of  some  programs.  Recursion  is 
required  to  avoid  unnecessarily  opaque,  complex,  and  confusin' 
programs  when  programs  operate  on  recursive  data  structures. 
Recursion  has  not  been  widely  used  in  DoD  software  because 
many  programming  languages  do  not  provide  recursion,  practi¬ 
tioners  are  not  famiJiar  with  its  use,  and  users  fear  that  ini 
run  time  costs  are  too  high.  Of  these,  only  the  run  time  corc- 
would  Justify  its  exclusion  from  the  language. 
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A  major  run  time  cost  often  attributed  to  recursion  Is  the 
need  for  the  presence  of  a  set  of  "display"  registers  which  are 
used  to  keep  track  of  the  addresses  of  the  various  levels  of  lex 
ically-embedded  environments  and  which  oust  be  managed  and  up¬ 
dated  at  run  time.  The  display,  however,  is  necessary  only  in 
programs  in  which  routines  access  variables  which  are  global  to 
their  own  definition,  but  local  to  a  more  global  recursive  pro¬ 
cedure.  This  possibility  can  easily  be  removed  by  prohibiting 
the  definition  of  procedures  within  the  body  of  a  recursive  pro¬ 
cedure.  The  utility  of  such  a  combination  of  capabilities  is 
very  questionable,  and  this  single  restriction  will  eliminate 
all  added  execution  costs  for  nonrecursive  procedures  in  pro¬ 
grams  which  contain  recursive  procedures. 

As  with  any  other  facility  of  the  language,  routines  should 
be  implemented  in  the  most  efficient  manner  consistent  with  thei 
use  and  the  language  should  be  designed  so  that  efficient  imple¬ 
mentations  are  possible.  In  particular,  the  most  efficient  im¬ 
plementation  for  nonrecursive  routines  should  be  possible,  re¬ 
gardless  of  whether  the  language  or  even  the  program  contains 
recursive  procedures.  When  any  routine  makes  a  procedure  call 
as  its  last  operation  before  exii;  (and  this  is  quite  comm.on 
for  recursive  routines)  the  imp?.ementatlon  might  use  the  same 
data  area  for  both  routines  and  do  a  Jump  to  the  head  of  the 
called  procedure,  thereby  saving  much  of  the  overhead  of  a  pro¬ 
cedure  call  and  eliminating  a  return.  The  choice  between  re¬ 
cursive  and  nonrecursive  routines  Involves  trade-offs.  Recur¬ 
sive  routines  can  aid  program  clarity  when  operating  on  recur¬ 
sive  data,  but  can  detract  from  clarity  when  operating  on  it¬ 
erative  data.  They  can  increase  execution  time  when  procedure 
call  overhead  is  greater  than  loop  overhead  and  can  decrease 
execution  times  when  loop  overhead  Is  the  more  expensive.  Fi¬ 
nally,  program  storage  for  recursive  routines  is  often  only  a 
small  fraction  of  that  for  a  corresptwidlng  Iterative  procedure. 
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but  the  data  storage  requirements  are  often  much  greater  be¬ 
cause  of  the  simultaneous  presence  of  several  activations  of 
the  same  procedure. 

G6.  The  Bourae  language  will  provide  a  par¬ 
allel  processing  capability .  This  cap¬ 
ability  should  include  the  ability  to 
create  and  terminate  (possibly  pseudo) 
parallel  processes  and  for  these  pro¬ 
cesses  to  gain  exclusive  use  of  resources 
during  specified  portions  of  their  execu¬ 
tion, 

A  parallel  processing  capability  is  essential  in  embedded 
computer  applications.  Programs  must  send  data  to,  recieve 
data  from,  and  control  many  devices  which  are  operating  in  par¬ 
allel.  Multiprogramming  (a  form  of  pseudo-parallel  processing) 
is  necessary  so  that  many  programs  within  a  system  can  meet 
their  differing  real  time  constraints.  The  parallel  processing 
capability  will  minimally  provide  the  ability  to  define  and  call 
parallel  processes  and  the  ability  to  gain  exclusive  use  of  sys¬ 
tem  resources  in  the  form  of  data  structures,  devices,  and  pseudo 
devices.  This  latter  ability  satisfies  one  of  the  two  needs  for 
synchronization  of  parallel  processes.  The  other  is  required  in 
conjunction  with  real  time  constraints  (see  G8). 

The  parallel  processing  capability  will  be  defined  as 
true  parallel  (as  opposed  to  coroutine)  primitives,  but  with 
the  understanding  that  in  most  implementations  the  object  com¬ 
puter  will  have  fewer  processors  (usually  one)  than  the  number 
of  parallel  paths  specified  in  a  program.  Interleaved  execu¬ 
tion  in  the  implementation  may  be  required. 

The  parallel  processing  features  of  the  language  should 
.be  selected  to  eliminate  any  unnecessary  overhead  associated 
with  their  use.  The  costs  of  parallel  processes  are  primarily 
in  run  time  storage  management.  As  with  recursive  routines. 
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most  accessing  and  storage-management  problems  can  be  elimi¬ 
nated  by  prohibiting  complex  interactions  with  other  language 
facilities  where  the  combination  has  little,  if  any,  utility. 

In  particular,  it  will  not  be  possible  to  define  a  parallel 
routine  within  the  body  of  a  recursive  routine  and  it  will  not 
be  possible  to  define  any  routine,  including  parallel  routines, 
within  the  body  of  those  parallel  routines  which  can  have  mul- 
tiple  simultaneous  activations.  If  the  language  permits  sev¬ 
eral  simultaneous  activations  of  a  given  parallel  process,  then 
it  might  require  the  user  to  give  an  upper  bound  on  the  number 
which  can  exist  simultaneously.  The  latter  requirement  is  rea¬ 
sonable  for  parallel  processes  because  it  is  information  known 
by  the  programmer  and  necessary  to  the  maintainer,  because  par¬ 
allel  processes  cannot  noimially  be  stacked,  and  because  it  is 
necessary  for  the  compilation  of  efficient  progrims. 

G7.  The  exception-handling  control  structure 
will  permit  the  user  to  cause  transfer  of 
control  and  data  foi'  any  error  or  excep¬ 
tion  situation  which  might  occur  in  a  pro¬ 
gram. 

It  is  essential  in  many  applications  that  there  be  no 
program  halts  beyond  the  user's  control.  The  user  must  be  able 
to  specify  the  action  to  be  taken  on  any  exception  situation 
which  might  occur  within  his  program.  The  exception-handling 
mechanism  will  be  parameterized  so  data  cein  be  passed  to  the 
recovery  point.  Exception  situations  might  Include  arithmetic 
overflow,  exhaustion  of  available  space,  hardware  errors,  any 
user-defined  exceptions,  and  any  run-time-detected  programming 
error. 

The  user  will  be  able  to  write  programs  which  can  get  out 
of  an  arbitrary  nest  of  control  and  Intercept  it  at  any  embed¬ 
ding  level  desired.  The  exception-handling  mechanism  will  per¬ 
mit  the  user  to  specify  the  action  to  be  taken  upon  the  occur¬ 
rence  of  a  designated  exception  within  any  given  access  ;.'Cope 
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of  the  program.  The  transfers  of  control  will,  at  the  user's 
option,  be  either  forward  in  the  program  (but  never  to  a  nar¬ 
rower  scope  of  access  or  out  of  a  procedure  through  its  lexical 
structure)  or  out  of  the  current  procedure  through  its  dynamic 
(i.e.,  calling)  structure.  The  latter  form  requires  an  excep¬ 
tion-handling  formal  parameter  class  (see  C7). 

G8.  There  will  be  sourae  language  features 
which  permit  delay  on  any  control  path 
until  lome  specified  time  or  s-f  tuation 
has  occurred,  which  permit  specification 
of  the  relative  priorities  among  parallel 
control  paths,  which  give  access  to  real 
time  clocks,  and  which  permit  asynchronous 
hardware  interrupts  to  be  treated  as  any 
other  exception  situatio.i . 

Vfhen  parallel  or  pseudo-parallel  paths  appear  in  a  pro¬ 
gram,  it  must  be  possible  to  specify  their  relative  priorities 
and  to  synchronize  their  executions.  Synchronization  can  be 
done  either  through  exclusive  access  to  data  (see  G6)  or 
through  delays  terminated  by  designated  situations  occurring 
within  the  program.  These  situations  should  Include  the  elapse 
of  program-specified  time  intervals,  occun?ence  of  hardware  in¬ 
terrupts,  and  those  designated  in  the  program.  There  will  be  no 
implicit  evaluation  of  program-determined  situations.  Time  de¬ 
lays  will  be  program-specifiable  for  both  real  and  simulated 
times . 

H.  SYNTAX  AND  COMMENT  CO.^VENTIONS 

HI.  The  source  language  will  be  free  format 
with  an  explicit  statement  deliaiter, 
will  allow  the  use  of  memonicalty  signif¬ 
icant  identifiers ^  will  be  based  on  con¬ 
ventional  forms,  will  have  a  simple,  un¬ 
iform,  and  easily  parsed  grammar,  will 
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not  provide  unique  notations  for 
special  cases^  will  not  permit  ab¬ 
breviation  of  identifiers  or  key 
wordsy  and  will  be  syntactically  un¬ 
ambiguous. 

Clarity  and  readability  of  programs  will  be  the  primary 
criteria  for  selecting  a  syntax.  Each  of  the  above  points  can 
contribute  to  program  clarity.  The  use  of  free  format,  mne¬ 
monic  identifiers,  and  conventional  forms  allo\JS  the  programmer 
to  use  notations  which  have  their  familiar  meanings,  to  put 
down  his  ideas  and  Intentions  in  the  order  and  form  that  hu¬ 
mans  think  about  them,  and  to  transfer  skills  he  already  has 
to  the  solution  of  the  problem  at  hand.  A  slmpl--*,  uniform 
language  reduces  the  number  of  cases  which  must  be  dealt  with 
by  anyone  using  the  language.  If  programs  are  difficult  for 
the  translator  to  parse,  they  will  be  difficult  for  people. 
Similar  things  should  use  the  same  notations  with  the  special- 
case  processing  reserved  for  the  translator  and  object  machine. 
The  purpose  of  mnemonic  identifiers  and  key  words  is  to  be  in¬ 
formative  and  Increase  the  distance  between  lexical  units  of 
programs.  This  does  not  prevent  the  use  of  short  identifiers 
and  short  key  words. 

B2,  The  user  will  not  be  able  to  modify  the 

source  language  syntax.  Specifically ,  he 
will  not  be  ablt  to  modify  operator  hier¬ 
archies,  introduce  new  precedence  rules, 
define  new  key  word  forms,  or  define  new 
operator  precedences . 

If  the  user  can  cheinge  the  syntax  of  the  language,  he  can 
change  the  basic  character  and  understanding  of  the  language. 
The  distinction  between  semantic  extensions  and  syntactic  ex¬ 
tensions  is  similar  to  that  between  being  able  to  coin  new 
words  in  English  or  being  able  to  move  to  another  natural 
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language.  Coining  words  requires  learning  those  new  meanings 
before  they  can  be  used,  but  at  the  same  tine  Increases  the 
power  of  the  language  for  some  applicationi .  Changing  the 
graimner,  (g.g.,  Franglis,  the  use  of  French  grammar  with  in¬ 
terspersed  English  words)  however,  undermines  the  basic  under¬ 
standing  of  the  language  itself,  changes  the  mode ’of  expi;esslon, 
and  removes  the  commonalities  which  obtain  between  various 
specializations  of  the  language.  Growth  of  a  language  through 
definition  of  new  data  and  operations  and  the  introduction  uf 
new  words  and  .'symbols  to  Identify  them  is  desirable,  but  there 
should  be  no  provision  for  changing  the  gramm.atical  rules  of 
the  language.  This  requirement  does  not  conflict  with  and 
does  not  preclude  associating  new  meaning  with  existing  opera¬ 
tors  . 

HZ.  The  syntax  cf  source-language  programs 
will  be  composable  from  a  character  set 
suitable  for  publication  purposes j  but 
no  feature  of  the  language  will  be  in¬ 
accessible  using  the  64-character  ASCII 
subset. 

A  common  language  should  use  notations  and  a  character  set 
convenient  for  communicating  algorithms,  prog.’ams,  and  program¬ 
ming  techniques  among  its  users.  On  the  other  hand,  the  langu¬ 
age  should  not  require  special  equipment  (e.g.,  card  readers 
and  printers)  for  its  use.  The  use  of  the  S^J-character  ASCII 
subset  v/ill  make  the  language  compatible  with  the  federal  in¬ 
formation  processing  standard  6iJ-character  set,  FIPS-1,  which 
has  been  adopted  by  the  U.S.A.  Standard  Code  for  Information 
Interchange  (USASCII).  The  language  definition  will  specify 
the  translation  from  the  publication  language  into  the  restricted 
character  set. 
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H4.  The  language  definition  will  provide 
the  formation  rules  for  identifiers 
and  literals ,  These  will  include  lit¬ 
erals  for  numbers  and  character  strings 
and  a  break  character  for  use  internal 
to  identifiers  and  literals . 

Lexical  units  of  the  language  should  be  defined  in  a  sim¬ 
ple,  uniform,  and  easily  understood  manner.  Some  possible 
break  characters  are  the  space  (i.e.,  any  number  of  spaces  or 
end-of-ilne) ,  the  underline,  and  the  tilde  (Refs.  8  and  9). 

The  space  cannot  be  used  if  identifiers  and  user-defined  in¬ 
fix  operators  are  lexically  indistinguishable,  but  in  such  a 
case,  the  formal  grammar  for  the  language  would  be  ambiguous 
(see  HI).  A  literal  break  character  contributes  to  the  read¬ 
ability  of  programs  and  makes  the  entry  of  long  litorals  less 
error-prone.  With  a  space  as  a  break  character,  one  can  enter 
multipart  (i.e.,  more  than  one  lexical  unit)  identifiers  such 
as  REAL  TIME  CLOCK  or  long  literals,  such  as,  2.14259  26535 
89793.  Use  of  a  break  can  also  be  used  to  guarantee  that  mis¬ 
sing  quote  brackets  on  character  literals  do  not  cause  errors 
which  propagate  beyond  the  next  end-of-line.  The  language 
should  require  separate  quoting  of  each  line  of  a  long  literal: 
"This  is  a  long" 

"literal  string". 

U5.  There  will  be  no  continuation  of  lexical 
units  across  lines,  but  there  will  be  a 
way  to  include  object  characters  such  as 
end-of-line  in  literal  strings. 

Many  elementary  input  errors  arise  at  the  end  of  lines. 
Programs  are  input  on  line-oriented  media,  but  the  concept  of 
end-of-line  is  foreign  to  free-format  text.  Most  of  the  error- 
prone  aspects  of  end-of-line  can  be  eliminated  by  not  allowing 
lexical  units  to  continue  over  lines.  The  sometimes  undesirable 
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effects  of  this  restriction  can  be  avoided  by  permitting  iden¬ 
tifiers  and  literals  to  be  composed  from  more  than  one  lexical 
unit  (see  H^<)  and  by  evaluating  constant  expressions  at  compile 
time  (see  Ci<). 

H6.  Key  uorda  will  be  reserved,  will  be  very 
few  in  number,  will  be  informative,  and 
will  not  be  usable  in  contexts  where  an 
identifier  can  be  used. 

By  key  words  of  the  language  are  meant  those  symbols  and 
strings  which  have  special  meaning  in  the  syntax  of  programs. 

They  introduce  special  syntactic  forms,  such  as  are  used  for 
control  structures  and  declarations,  or  they  are  used  as  infix 
operators,  or  as  some  form  of  parenthesis.  To  avoid  confusion 
and  ambiguity,  key  words  will  be  reserved,  that  is,  not  used 
as  identifiers.  Key  words  will  be  few,  because  each  new  key 
word  Introduces  another  case  in  the  parsing  rules,  adding  to 
the  complexity  of  the  language,  also,  too  many  key  words  in¬ 
convenience  and  complicate  the  programmer's  task  of  choosing 
informative  identifiers.  Key  words  should  be  concise,  but  it 
is  more  Iraportcint  that  they  be  informative  than  short.  A  major 
exception  is  the  key  word  introducing  a  comment;  in  this  case, 
the  comment,  not  its  key  word,  should  do  the  informing.  Finally, 
there  will  be  no  place  in  a  source  language  program  in  which  a 
key  word  can  be  used  in  place  of  an  identifier.  That  is,  func¬ 
tional  form  operations  and  special  data  items  built  into  the 
language  or  accessible  as  a  standard  extension  will  not  be 
treated  as  key  words  but  will  be  treated  as  any  other  identi¬ 
fier. 
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E7 .  The  source  language  will  have  a  eingle^ 
uniform  comment  convention.  Comments 
will  be  easily  distinguishable  from 
oodsj  will  be  introduced  by  one  or 
possibly  two  language-defined  charac- 
terSf  will  permit  any  combination  of 
characters  to  appear^  will  be  able  to 
appear  at  any  reasonable  point  in  a  pro- 
gramj  will  automatically  terminate  at  end- 
of-line  if  not  otherwise  terminated^  and 
will  not  prohibit  automatic  reformatting 
of  programs . 

These  are  all  obvious  points  that  will  encourage  the  use 
of  comments  in  programs  and  avoid  their  error-prone  features 
in  some  existing  languages.  Comments  at  any  reasonable  point 
in  a  program  will  not  be  taken  to  mean  that  they  can  appear 
internally  in  a  lexical  unit,  such  as  an  identifier,  key  word, 
or  between  the  opening  and  closing  brackets  of  a  character 
string.  One  comment  convention  which  nearly  meets  these  cri¬ 
teria  is  to  have  a  special  quote  character  which  begins  com¬ 
ments  and  with  either  the  quote  or  an  end-of-llne  ending  each 
comment.  This  allows  both  embedded  and  line-oriented  comments. 

H8.  The  language  will  not  permit  unmatched 
parentheses  of  any  kind. 

Some  programming  languages  permit  closing  parentheses  to 
be  omitted.  If,  for  example,  a  program  contained  more  BEGINs 
than  ENDsj  the  translator  might  insert  enough  ENDs  at  the  end 
of  the  program  to  make  up  the  difference.  This  makes  programs 
easier  to  write  because  it  sometimes  saves  the  programmer  writ¬ 
ing  several  ENDs  at  the  end  of  programs  and  because  it  elimi¬ 
nates  all  syntax  errors  for  missing  ENDs.  Failure  to  require 
proper  parentheses-matchlng  makes  it  more  difficult  to  write 
.•orrect  programs.  Good  programming  practice  requires  that 
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matching  parentheses  be  included  in  programs,  whether  or  not 
they  are  required  by  the  language.  Unfortunately,  if  they 
are  not  required  by  the  language,  there  can  be  no  syntax  check 
to  discover  where  errors  were  made.  The  language  will  require 
full  parentheses-matching .  This  does  not  preclude  syntactic 
features  such  as  case  x  of  s^,  end  case  in  which  end 

is  paired  with  a  key  word  other  than  begin.  Nor  does  it,  alone, 
prohibit  open  forms  such  as  if -then-els e- . 

H9.  There  will  be  a  uniform  referent  notation . 

The  distinction  between  function  calls  and  data  reference 
is  one  of  representation,  not  of  use.  Thus,  thei-e  will  be  no 
language-imposed  syntactic  distinction  between  function  calls 
and  data  selection.  If,  for  example,  a  computed  function  is 
replaced  by  a  lookup  table,  there  should  be  no  need  to  change 
the  calling  program.  This  does  not  preclude  the  inclusion  of 
more  than  one  referent  notation. 

HIO.  No  language-defined  symbols  appearing  in 
the  same  context  will  have  essentially 
different  meanings . 

This  contributes  to  the  clarity  and  uniformity  of  programs, 
protects  against  psychological  ambiguity,  and  avoids  some  er¬ 
ror-prone  features  of  extant  languages.  In  particular,  this 
would  exclude  the  use  of  =  to  imply  both  assignment  and  equal¬ 
ity,  would  exclude  conventions  implying  that  parenthesized  para¬ 
meters  have  special  semantics  (as  with  PL/1  subroutines),  and 
would  exclude  the  use  of  an  assignment  operator  for  other  than 
assignment  {e.g.,  left-hand-side  function  calls).  It  would  not, 
however,  require  different  operator  symbols  for  integer,  real, 
or  even  matrix  arithmetic,  since  these  are,  in  fact,  special 
cases  of  the  same  abstract  operations,  and  would  allow  the  use 
of  generic  functions  applicable  to  several  data  types. 


112 


I.  DEFAULTS,  CONDITIONAL  COMPILATION,  AND  LANGUAGE  RESTRICTIONS 


11,  There  will  be  no  defaults  in  programs  which 
affect  the  program  logic.  That  is,  decisions 
which  affect  program  logic  will  be  made  either 
irrevocably  when  the  language  is  defined,  or 
explicitly  in  each  program. 

The  only  alternative  is  implementation-dependent  defaults, 
with  the  translator  determining  the  meaning  of  programs.  What 
a  program  does  should  be  determinable  from  the  program  and  the 
defining  documentation  for  the  programming  language.  This  does 
not  require  that  binding  of  all  program  properties  be  local  to 
each  use.  Quite  the  contrary,  it  would,  for  example,  allow  au¬ 
tomatic  definition  of  assignment  for  all  variables  or  global 
specification  of  precision.  What  it  does  require  is  that  each 
decision  be  explicit:  in  the  language  definition,  global  to 
some  scope,  or  local  to  each  use.  Omission  of  any  selection 
which  affects  the  program  logic  will  be  treated  as  an  error  by 
the  translator. 

12.  Defaults  will  be  provided  for  special  capa¬ 
bilities  affecting  only  object  representa¬ 
tion  and  other  properties  which  the  program¬ 
mer  does  not  know  or  care  about.  Such  de¬ 
faults  will  always  mean  that  the  programmer 
does  not  care  which  choice  is  made.  The  pro¬ 
grammer  will  be  able  to  override  these  defaults 
when  necessary . 

The  language  should  provide  a  high  degree  of  management 
control  and  visibility  to  programs  and  seif-documenting  pro¬ 
grams,  with  the  programmer  required  to  make  his  decision  ex¬ 
plicit.  On  the  other  hand,  the  programmer  should  not  be  forced 
to  overspecify  his  programs  and  thereby  cloud  their  logic,  un¬ 
necessarily  eliminate  opportunities  for  optimization,  and  mis¬ 
represent  arbitrary  choices  as  essential  to  the  program  logic. 


Defaults  will  be  allowed,  in  fact  encouraged,  in  "don't  care" 
situations.  Such  defaults  will  include  data  representations 
(see  Ji)),  open  vs,  closed  subroutine  calls  (see  J5),  and  re¬ 
entrant  vs.  nonreentrant  code  generation. 

13.  The  user  w'.ll  be  able  to  associate  compile^ 
time  variables  with  programs .  These  will 
include  variables  which  specify  the  object 
computer  model  and  other  ajpects  of  the  ob~ 
ject  machine  configuration. 

When  a  language  has  different  host  and  object  machines, 
and  when  its  compilers  can  produce  code  for  several  configura¬ 
tions  of  a  given  machine,  the  programm.er  should  be  able  to 
specify  the  intended  object-machine  configuration.  The  user 
should  have  control  over  the  complle-tlme  variables  used  in 
his  program.  Typically,  they  would  be  associated  with  the  ob¬ 
ject  computer  model;  memory  size;  special  hardware  options; 
operating  syst'm,  if  present;  peripheral  equipment;  or  ether 
aspects  of  the  object-machine  configuration.  Compile-tir.e 
variables  will  be  set  outside  the  program,  but  available  for 
interrogation  within  the  program  (see  and  C^t). 

14.  The  source  language  will  permit  the  use  of 
conditional  statements  (e.g.^  case  state¬ 
ments)  dependent  on  the  object  environment 
and  other  compile-time  variables.  In  such 
cases,  the  conditional  will  be  evaluated  at 
compile  time  and  only  the  selected  path  will 
be  compiled. 

An  environmental  inquiry  capability  permits  the  writing  c 
common  programs  and  procedures  which  are  specialized  at  com¬ 
pile  time  by  the  translator  as  a  function  of  the  intended  ob¬ 
ject-machine  configuration  or  of  other  complle-time  variables 
(see  13).  This  requirement  is  a  special  case  of  evaluation  of 
constant  expressions  at  compile  tine  (see  C4).  It  provides  a 
general-purpose  capability  for  conditional  compilation. 
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15,  The  source  language  will  contain  a  simple, 
clearly  identifiable  base  which  houses  all 
the  power  of  the  language .  To  the  extent 
possible ,  the  base  will  be  minimal,  with 
each  feature  providing  a  single  unique 
capability  not  otherwise  duplicated  in  the 
base.  The  choice  of  the  base  will  not  de¬ 
tract  from  the  efficiency,  safety,  or  un- 
derstandability  of  the  language , 

The  capabilities  available  in  any  language  can  be  parti¬ 
tioned  into  two  groups,  those  definable  within  the  base,  and 
those  providing  an  essential  primitive  capability  of  the  lang¬ 
uage.  The  smaller  eind  simpler  the  base,  the  easier  the  lang¬ 
uage  will  be  to  learn  and  use.  A  clearly  delineated  base,  with 
features  not  in  the  base  defined  in  terms  of  the  base,  will 
improve  the  ease  and  efficiency  of  learning,  implementing,  and 
maintaining  the  language.  Only  the  base  need  be  implemented  to 
make  the  full  source-language  capability  available. 

Base  features  will  provide  relatively  low-leveled  general- 
purpose  capabilities  not  yet  specialized  for  particular  appli¬ 
cations.  There  will  be  no  prohibition  on  a  translator  incor¬ 
porating  specialized  optimizations  for  particular  extensions. 
Any  extension  provided  by  a  translator  will,  however,  be  de¬ 
finable  within  the  base  language,  using  the  built-in  definition 
facilities.  Thus,  programs  using  the  extension  will  be  trans¬ 
latable  by  any  compiler  for  the  language,  but  not  necessarily 
with  the  same  object  efficiency. 

16.  Language  restrictions  which  are  dependent 
only  on  the  translator  and  not  on  the  ob¬ 
ject  machine  will  be  specified  explicitly 
in  the  language  definition. 
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Limits  on  the  number  of  array  dimensions,  the  length  of 
identifiers,  the  niyil^er  of  nested  parentheses  levels  in  expres¬ 
sions,  or  the  number  of  identifiers  in  programs  are  determined 
by  the  translator  and  not  by,  the  object  machine.  Ideally,  the 
limits  should  be  set  so  high  that  no  program  (save  the  most 
abrasive)  encounters  the  limits.  In  each  case,  however,  (a) 
some  limit  must  be  set,  (b)  whatever  the  limit,  it  ;<ill  affect 
some  program  and  therefore  must  be  known  by  the  users  of  the 
translator,  (c)  letting  each  translator  set  its  own  limits  means 
that  programs  will  not  be  portable,  (d)  setting  the  limits  very 
high  requires  that  the  translator  be  hosted  only  on  large  ma¬ 
chines,  and  (e)  quite  low  limits  do  not  impose  significantly 
on  either  the  power  of  the  language  or  the  readability  of  pro¬ 
grams.  Thus,  the  limits  should  be  set  as  part  of  the  language 
definition.  They  should  be  small  enough  that  they  do  not  domi¬ 
nate  the  compiler,  and  large  enough  that  they  do  not  interfere 
with  the  usefulness  of  the  language.  If  they  were  set  at,  say, 
the  99-percent  level,  based  on  statistics  from  existing  DoD 
computer  programs,  the  limits  might  be  a  few  hundred  for  num¬ 
bers  of  identifiers  and  less  than  ten  in  the  other  cases  men¬ 
tioned  above. 

17.  Language  restrictions  which  are  inherently 
dependent  only  on  the  object  environment 
will  not  be  built  into  the  language  defi¬ 
nition  or  any  translator. 

Limits  on  the  amount  of  run-time  storage,  access  to  spe¬ 
cialized  peripheral  equipment,  use  of  special  hardware  capa¬ 
bilities,  and  access  to  real  time  clocks  are  dependent  on  the 
object  machine  and  configuration.  The  translator  will  report 
when  a  program  exceeds  the  resources  or  capabilities  of  the  in¬ 
tended  object  machine  but  will  not  build  in  arbitrary  limits 
of  its  own. 
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J.  EFFICIENT  OBJECT  REPRESENTATIONS  AND  MACHINE  DEPENDENCIES 


Jl.  The  language  and  its  translators  will  not 
impose  run  time  costs  for  unneeded  or  un¬ 
used  generality .  They  will  be  capable  of 
producing  efficient  code  for  all  programs . 

The  base  language  eind  library  definitions  might  contain 
features  and  capabilities  not  needed  by  everyone,  or  not  by 
everyone  all  the  time.  The  leinguage  should  not  force  programs 
to  require  greater  generality  than  they  need.  When  a  program 
does  not  use  a  feature  or  capability,  it  should  pay  no  run  time 
cost  for  the  feature  being  in  the  language  or  library.  When 
the  full  generality  of  a  feature  is  not  used,  only  the  neces¬ 
sary  (reduced)  cost  should  be  paid.  Where  possible,  language 
features  (such  as  automatic  and  dynamic  array  allocation,  proc¬ 
ess  scheduling,  file  management,  and  I/O  buffering)  which  re¬ 
quire  run  tire  support  packages  should  be  provided  as  standard 
library  definitions  and  not  as  part  of  the  base  language.  The 
user  will  not  have  to  pay  time  and  space  for  support  packages 
he  does  not  use.  Neither  will  there  be  automatic  movement  of 
programs  or  data  between  main  storage  £Uid  backing  storage  which 
is  not  under  program  control  (unless  the  object  machine  has 
virtual  memory  with  underlying  management  beyond  the  control 
of  all  Its  users).  Language  features  will  result  in  special 
efficient  object  code  when  their  full  generality  is  not  used. 

A  large  number  of  special  cases  should  compile  efficiently. 

For  example,  a  program  performing  numeric  calculations  on  un- 
subscripted  real  variables  should  produce  code  no  worse  than 
FORTRAN.  Parameter-passing  for  single-argument  routines  might 
be  implemented  much  less  expensively  than  multiple-argument 
routines . 

One  way  to  reduce  costs  for  unneeded  capabilities  is  to 
have  a  base  language  whose  data  structures  and  operations  pro¬ 
vide  a  single  capability  which  is  composable  and  has  a  straight¬ 
forward  implementation  in  the  object  code  of  conventional 
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architecture  machines.  If  the  base  language  components  are 
easily  composable,  they  can  be  used  to  construct  the  specialized 
structures  needed  by  specific  applications,  if  they  are  simple 
and  provide  a  single  capability,  they  will  not  force  the  use  of 
unneeded  capabilities  in  order  to  obtain  needed  capabilities, 
eind  if  they  are  compatible  with  the  features  normally  found  in 
sequential  uniprocessor  digital  computers  with  random  access 
memory,  they  will  have  near-minimum  or  at  least  low-cost  imple- 
mei^tation  on  many  object  machines. 

J2.  Any  optimizations  peTformed  hy  the  trans¬ 
lator  will  not  change  the  effect  of  the 
program. 

More  simply,  the  translator  cannot  give  up  program  reli¬ 
ability  and  correctness,  regardless  of  the  excuse.  Mote  that 
for  most  programming  languages,  there  are  few  known  safe  opti¬ 
mizations  and  many  unsafe  ones.  The  number  of  applicable  safe 
optimizations  can  be  Increased  by  making  more  information  avail¬ 
able  to  the  compiler  and  by  choosing  language  constructs  which 
allow  safe  optimizations.  This  allows  optimization  by  code 
motion,  providing  that  motion  dees  not  change  the  effect  of  the 
program. 

J3.  The  source  language  will  provide  encapsu¬ 
lated  access  to  machine-dependent  hardware 
facilities f  including  machine  language  code 
insertions . 

It  is  difficult  to  be  enthusiastic  about  machine  language 
insertions.  They  defeat  the  purpose  of  machine  independence; 
constrain  the  implementation  techniques;  complicate  the  diag¬ 
nostics;  impair  the  safety  of  type  checking;  and  detract  from 
the  reliability,  readability,  and  modifiability  of  programs. 

The  use  of  machine  language  insertions  is  particularly  danger¬ 
ous  in  multiprogramming  applications,  because  they  impair  the 
ability  to  exclude,  a  priori y  a  large  class  of  time-dependent 
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bugs.  Rigid  enforcement  of  scope  rules  by  the  compiler  in 
real-time  applications  is  a  powerful  tool  to  ensure  that  one 
sequential  process  will  not  Interfere  with  others  in  an  uncon¬ 
trolled  fashion.  Similarly,  when  several  independent  programs 
are  executed  in  an  interleaved  fashion,  the  correct  execution 
of  each  may  depend  on  the  others  not  improperly  'ising  machine 
language  insertions. 

Unfortunately,  machine  language  insertions  are  necessary 
for  interfacing  special-purpose  devices,  for  accessing  special- 
purpose  hardware  capabilities,  and  for  certain  code  optimiza¬ 
tions  on  time-critical  paths.  Here  we  have  an  example  of 
Dijkstra’s  dilemma  (see  Chapter  I,  Section  B),  in  which  the 
mismatch  between  high-level  language  programming  and  the  under¬ 
lying  hardware  is  unacceptable  and  there  is  no  feasible  way  to 
reject  the  hardware.  The  only  remaining  alternative  is  to 
"continue  bit  pushing  in  the  old  way,  with  all  the  known  ill 
effects".  Those  ill  effects  can,  however,  be  constrained  to 
the  smallest  possible  perimeter,  in  practice,  if  not  in  theory. 
The  ability  to  enter  machine  language  should  not  be  used  as  an 
excuse  to  exclude  otherwise-needed  facilities  from  the  HOL; 
the  abstract  descriotion  of  programs  in  the  HOL  should  not  re¬ 
quire  the  use  of  machine  language  insertions.  The  semantics 
of  machine  language  Insertions  will  be  determinable  from  the 
HOL  definition  and  the  object  machine  description  alone,  and 
not  dependent  on  the  translator  characteristics.  Machine  lang¬ 
uage  insertions  will  be  encapsulated  so  they  can  be  easily  rec- 
og.nlzed  and  so  that  it  is  clear  which  variables  and  program 
identifiers  are  accessed  within  the  Insertion.  The  machine- 
language  insertions  will  be  permitted  only  within  the  body  of 
compile  time  conditional  statements  (see  I^),  which  depend  on 
the  object-machine  configuration  (see  13).  They  will  not  be 
allowed  to  be  interspersed  with  executable  statements  of  the 
source  language. 
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J4.  It  wilt  be  possible  within  the  source 
language  to  specify  the  object  repre¬ 
sentation  of  composite  data  structures . 

These  descriptions  will  be  optional  and 
encapsulated  and  will  be  distinct  from 
the  logical  description.  The  user  will 
be  able  to  specify  the  time/space  trade¬ 
off  to  the  translator.  If  not  specified, 
the  object  representation  will  be  optimal, 
as  determined  by  the  translator. 

It  is  often  necessary  to  give  detailed  specifications  of 
the  object  data  representations  to  obtain  r.axinurn  density  for 
large  data  files,  to  meet  format  requirements  Imposed  by  the 
hardware  or  peripheral  equipment,  to  allow  special  optimiza¬ 
tions  on  time-critical  paths,  or  to  ensure  compatibility  when 
transferring  data  between  machines. 

It  will  be  possible  to  specify  the  order  of  fields,  the 
width  of  fields,  the  presence  of  "don’t  care"  fields,  and  the 
position  of  word  boundaries.  It  will  be  possible  to  associate 
source-language  identifiers  (data  or  program)  with  special  ma¬ 
chine  addresses.  The  use  of  machine-dependent  characteristics 
of  the  object  representation  will  be  restricted,  as  with  ma¬ 
chine-dependent  code  (see  J3).  When  multiple  fields  per  wc'"d 
are  specified,  the  compiler  may  have  to  generate  somie  form  of 
shift  and  mask  operations  for  source-program  references  and 
assignments  to  those  variables  {i.e.,  fields).  As  with  ma¬ 
chine-language  insertions,  object  data  specifications  should 
be  used  sparingly  and  the  language  features  for  their  use  mmst 
be  Spartan. 

If  the  object  representation  of  a  composite  data  object 
is  not  specified  in  the  source  program,  there  will  be  no  spe¬ 
cific  default  guaranteed  by  the  translator.  The  translator 
might,  for  example,  attempt  to  minimize  access  time  and/or 
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memory  space  in  determining  the  object  representation.  It 
might,  depending  on  the  object-machine  characteristics,  as¬ 
sign  variables  and  fields  of  records  to  full  words,  but  assign 
array  elements  to  the  smallest  of  bits,  bytes,  half  words, 
words,  or  exact-multiple  words  permitted  by  the  logical  descrip¬ 
tion. 

JS.  The  programmer  will  he  able  to  specify 
whether  calls  on  a  routine  are  to  have 
an  open  or  closed  implementation.  An 
open  and  a  closed  routine  of  the  same 
description  will  have  identical  seman¬ 
tics. 

The  use  of  inline  open  procedures  can  reduce  the  run  tine 
execution  costs  significantly  in  some  cases.  There  are  the 
obvious  advantages  in  eliminating  the  parameter  passing,  in 
avoiding  the  saving  of  return  marks,  and  in  not  having  to  pass 
arguments  to  and  from  the  routine.  A  less  obvious,  but  often 
more  important,  advantage  in  saving  run  time  costs  is  the  abil¬ 
ity  to  execute  constant  portions  of  routines  at  compile  time 
and,  thereby,  eliminate  time  and  space  for  those  portions  of 
the  procedure  body  at  run  time.  Open  routine  capability  is 
especially  Important  for  machine-language  Insertions. 

The  distinction  between  open  and  closed  implementation 
of  a  routine  is  an  efficiency  consideration  and  should  not  af¬ 
fect  the  function  of  the  routine.  Thus,  an  open  routine  will 
differ  from  a  syntax  macro  in  that  (a)  its  global  environment 
is  that  of  its  definition  and  not  that  of  its  call  and  (b) 
multiple  occurrences  of  a  formal  value  (i.e.,  read  only)  para¬ 
meter  in  the  body  have  the  same  value.  If  a  routine  is  not 
specified  as  either  open  or  closed,  the  choice  will  be  optimal 
(with  respect  to  space  or  time)  as  determined  by  the  translator. 
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VI.  CHARACTERISTICS  NEEDED  FOR  OTHER  ASPECTS 
OF  THE  COMMON-LANGUAGE  EFFORT 

The  material  reported  in  this  chapter  was  generated  by  the 
Services  at  the  same  time  as  the  technical  characteristics 
described  in  the  preceding  Chapter  but  is  concerned  with  the 
translators,  support  software,  documentation,  training,  stand¬ 
ards,  application  libraries,  management  policy,  and  procure¬ 
ment  practices  for  the  common  language  and  its  use.  These  is¬ 
sues  are  important,  while  mistakes  aind  oversights  in  the  tech¬ 
nical  characteristics  can  guarantee  failure  of  the  common-lang¬ 
uage  effort,  success  is  not  guaranteed,  no  matter  how  techni¬ 
cally  meritorious  the  resulting  language.  Success  can  only  be 
guaranteed  by  close  attention  to  a  variety  of  nontechnical  Is¬ 
sues,  including  those  considered  below. 

Several  of  these  issues,  including  those  of  implementation, 
documentation,  and  support  will  either  directly  or  indirectly 
affect  the  acceptability  of  candidate  languages.  As  with  the 
needed  technical  characteristics  for  the  common  language,  the 
issues  raised  here  are  often  not  resolved  at  the  most  detailed 
level.  Until  more  detailed  characteristics  of  the  language  come 
into  focus,  there  is  no  rationale  with  which  to  resolve  all  these 
issues  in  detail. 


Preceding  page  blank 
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A.  PROGRAM  ENVIRONMENT 


Kl.  The  language  will  not  require  that  the 

object  machine  have  an  operating  system. 

When  the  object  machine  does  have  an  op¬ 
erating  system  or  executive  program,  the 
hardware /operating  system  combination  will 
be  interpreted  as  defining  an  abstract  ma¬ 
chine  which  acts  as  the  object  machine  for 
the  translator. 

A  language  definition  cannot  dictate  the  architecture  of 
existing  object  machines,  whether  defined  entirely  in  hardware 
or  in  a  hardware/software  combination.  It  can  provide  a  source- 
language  representation  of  all  the  needed  capabilities  and  at¬ 
tempt  to  choose  these  so  they  have  an  obvious  and  efficient 
translation  in  the  object  machines. 

K2.  The  language  will  support  the  integration 
of  separately  written  modules  into  an  op¬ 
erational  program. 

Separately  written  modules  in  the  fomt  of  routines  and 
type  definitions  are  necessary  for  the  isanagement  of  large 
software  efforts  and  for  effective  use  of  libraries.  The 
user  will  be  able  to  cause  anything  in  anj  accessible  library 
to  be  inserted  into  his  program.  This  is  a  requirement  for 
separate  definition  but  not  necessarily  for  separate  compila¬ 
tion.  The  decision  as  to  whether  separately  defined  program 
modules  are  to  be  maintained  in  source  or  object  language  form 
is  a  question  of  implementarion  efficiency,  will  be  a  local 
management  option  and  will  not  be  Imposed  ifcy  the  language  defi¬ 
nition.  The  trade-offs  Involved  are  complicated  by  other  re¬ 
quirements  for  type  checking  of  parameters  ((see  C6),  for  open 
subroutines  (see  J5)>  for  efficient  object  representations 
(see  Jl),  and  for  constant  expression  evaluation  at  compile 
time  (see  C4).  In  general,  separate  compilation  increased  the 
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difficulty  and  expense  of  the  interface  validations  needed  for 
progj'ain  safety  and  reliability  and  detracts  from  object  pro- 
gra)a  f^fficiency  by  removing  many  of  the  optimizations  otherwise 
possible  at  the  interfaces,  but  at  the  same  time  it  reduces  the 
cost  and  con-plexity  of  compilation. 

K3.  A  family  of  programming  tools  and  aids  in 
the  form  of  support  packages  including 
linkers t  loaders^  and  debugging  systems 
will  be  made  available  with  the  language 
and  its  translators.  There  will  be  a  con¬ 
sistent,  easily  used  user  interface  for 
these  tools. 

No  longer  can  a  programming  language  be  considered  sep¬ 
arately  from  its  programming  environment.  The  availability  of 
programming  tools  which  need  not  be  developed  or  supported  by 
individual  projects  is  a  major  factor  in  the  acceptability  of 
a  language.  There  is  no  need  to  restrict  the  kinds  or  form  of 
support  software  available  in  the  programming  environment,  and 
continued  development  of  new  tools  should  be  encouraged  and 
made  available  in  a  competitive  market.  It  is,  however,  desir¬ 
able  that  tools  be  developed  in  their  own  source  language  to 
simplify  their  portability  and  maintainability. 

K4.  A  variety  of  useful  options  to  aid  gene¬ 
ration,  test,  documentation,  and  modifi¬ 
cation  of  programs  will  be  provided  as 
support  software  available  with  the  lang¬ 
uage  or  as  translator  options .  As  a  mini¬ 
mum,  these  will  include  program  editing, 
post-mortem  analysis  and  diagnostics ,  pro¬ 
gram  reformatting  for  standard  identations , 
and  cross-reference  generation . 

There  will  be  special  facilities  to  aid  the  generation, 
test,  documentation,  and  modification  of  programs.  The  "best" 
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set  of  capabilities  and  their  proper  form  is  not  currently 
known.  Since  nonstandard  translator  options  and  availability 
of  nonstandard  software  tools  and  aids  do  not  adversely  affect 
software  commonality,  the  language  definition  and  standards 
will  not  dictate  arbitrary  choices.  Instead,  the  development 
of  language-associated  tools  and  aids  will  be  encouraged  within 
the  constraint  of  implementing  and  supporting  the  source  langu¬ 
age,  as  defined.  Tools  and  debugging  aids  will  be  source-lang¬ 
uage  oriented. 

Some  of  the  translator  options  which  have  been  suggested 
and  may  be  useful  Include  the  following.  Code  might  be  com¬ 
piled  for  assertions  which  would  give  run  time  warnings  when 
the  value  of  the  assertion  predicate  is  false.  It  might  pro¬ 
vide  run-time  tracing  of  specified  program  variables.  Dimen¬ 
sional  analysis  might  be  done  on  units-of-measure  specifica¬ 
tions.  Special  optimizations  might  be  invoked.  There  might 
be  capability  for  timing  analysis  and  gathering  run-time  sta¬ 
tistics.  There  might  be  translator-supplied  feedback  to  pro¬ 
vide  management  visibility  regarding  progress  and  conformity 
with  local  conventions.  The  user  might  be  able  to  inhibit  code 
generation.  There  might  be  facilities  for  compiling  program 
patches  and  for  controlling  access  to  language  features.  The 
translator  might  provide  a  listing  of  the  number  of  instruc¬ 
tions  generated  against  corresponding  source  inputs  or  an  es¬ 
timate  of  their  execution  times.  It  might  provide  a  variety 
of  listing  options. 

K5,  The  source  language  will  permit  inclusion 

of  assertions,  assumptions ,  axiomatic  defi¬ 
nitions  of  data  types,  debugging  specifica¬ 
tions,  and  units  of  measure  in  programs . 

Because  many  as sertional  methods  are  not  yet 
powerful  enough  for  practical  use,  nor  suf¬ 
ficiently  well  developed  for  standardization, 
they  will  have  the  status  of  comments. 
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Tt;ere  are  many  opinions  on  the  desirability,  usefulness, 
and  proper  form  for  each  of  these  specifications.  Better  pro¬ 
gram  documentation  is  needed  and  specifications  of  these  kinds 
may  help.  Specifications  also  Introduce  the  possibility  of 
automated  testing,  run-time  verification  of  predicates,  for¬ 
mal  program  proofs,  and  dimensional  analysis.  The  language 
will  not  prohibit  inclusion  of  these  forms  of  specification  if 
and  when  they  become  available  for  practical  use  in  programs. 
Assertions,  assumptions,  axiomatic  definitions,  and  units  of 
measure  in  source-language  programs  should  be  enclosed  in 
special  brackets  and  treated  as  interpreted  comments  —  com¬ 
ments  delimited  by  special-comment  brackets  and  which  may  be 
interpreted  during  translation  or  debugging  to  provide  units 
analysis,  verification  of  assertions  and  assumptions,  etc.  — 
but  whose  interpretation  would  be  optional  to  translator  im¬ 
plementations  . 

B.  TRANSLATORS 

LI.  No  implementation  of  the  language  will  con¬ 
tain  s our cer language  features  which  are  not 
defined  in  the  language  standard.  Any  inter¬ 
pretation  of  a  language  feature  not  explicitly 
permitted  by  the  language  definition  will  be 
forbidden . 

This  guarantees  that  use  of  programs  and  software  sub¬ 
systems  will  not  be  restricted  to  a  particular  site  by  virtue 
of  using  their  unique  version  of  the  language.  It  also  rep¬ 
resents  a  commitment  to  freezing  the  source  language,  inhibit¬ 
ing  innovations  and  growth  in  the  form  of  the  source  language, 
and  confining  the  base  language  to  the  current  state  of  the 
art  in  return  for  stability,  wider  applicability  of  software 
tools,  reusable  software,  greater  software  visibility,  and  in¬ 
creased  payoff  for  tool-building  efforts.  It  does  not,  however, 
disallow  library  definition  optimizations  which  are  translator- 
unique  . 
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L2.  Every  translator  for  the  language  h,ill 

implement  the  entire  base  language .  There 
will  be  no  subset  implementations  of  the 
base  language . 

If  individual  compilers  implement  only  a  subset  of  the 
language,  then  there  is  no  chance  for  software  commonality. 

If  a  translator  does  not  implement  the  entire  language,  it 
cannot  give  its  users  access  to  standard  supported  libraries 
or  to  application  programs  Implemented  on  seme  other  transla¬ 
tor.  Requiring  that  the  full  language  be  Implemented  will  be 
expensive  only  if  the  base  language  is  large,  complex,  and  non- 
uniform.  The  intended  source  language  product  from  this  ef¬ 
fort  is  a  small,  simple,  uniform  base  lanauage  with  the  spe¬ 
cialized  features,  support  packages,  and  com.plex  features  rel¬ 
egated  to  library  routines  not  requiring  direct  translator 
support.  If  simple,  low-cost  translators  are  not  feasible  for 
the  selected  language,  then  the  language  is  too  large  and  com¬ 
plex  to  be  standardized  and  the  goal  of  language  commonality 
will  not  be  achievable. 


L3.  The  translator  will  minimize  compile  time 
costs.  A  goal  of  any  translator  for  the 
language  will  he  low-cost  translation, 
(when  optimization  is  disabled) . 


Where  practical  and  beneficial,  the  user  will  have  con¬ 
trol  over  the  level  of  optimization  applied  to  his  program.s  • 

The  programmer  will  have  control  over  the  trade-offs  betv;een 
compile-tim.e  and  run-time  costs.  The  desire  for  sm.all,  effi¬ 
cient  translators  that  can  be  hosted  by  machines  with  lim.ited 
size  and  capability  should  influence  the  design  of  the  base 
language  against  Inclusion  of  unnecessary  features  and  towards 
systematic  treatment  of  features  which  are  included.  The  goal 
will  be  effective  use  of  the  available  m.achines,  both  in  ob¬ 
ject  execution  and  translation,  and  not  maximal  speed  of  trans- 
latlon. 


Translation  costs  depend  not  only  on  the  compiler  but  the 
language  design.  Both  the  translator  and  the  language  design 
will  emphasize  low-cost  translation,  but  in  an  environment  of 
large  and  long-lived  software  products,  this  will  be  secondary 
to  requirements  for  reliability  and  maintainability.  Language 
features  will  be  chosen  to  ensure  that  they  do  not  Impose  costs 
for  unneeded  generality  and  that  needed  capabilities  can  be 
translated  into  efficient  object  representations.  This  means 
that  the  inherent  costs  of  specific  language  features  in  the 
context  of  the  total  language  must  be  understood  by  the  de¬ 
signers,  implementers ,  and  users  of  the  language.  One  conse¬ 
quence  should  be  that  trivial  programs  com.pile  and  run  in  triv-- 
ial  time.  On  the  other  hand,  significant  optimization  is  not 
expected  from  a  minimal  cost  translation. 

L4 .  Translators  will  be  able  to  produce  code  for 
a  variety  of  object  nachines.  The  machine- 
independent  parts  of  translators  might  be 
built  independently  of  the  code  generators. 

There  is  currently  no  common,  widely  used  computer  in  the 
DoD.  There  are  at  least  250  different  models  of  commercial 
machines  in  use,  along  with  many  specialized  machines.  A  com¬ 
mon  language  must  be  applicable  to  a  wide  variety  of  models 
and  sizes  of  machines.  Translators  might  be  written  so  they 
can  produce  object  code  for  several  machines.  This  reduces 
the  proliferation  of  translators  and  caKes  the  full  power  of 
an  existing  translator  available  at  the  cost  of  producing  an 
additional  code  generator. 

L5.  The  translator  need  not  he  able  to  run  on 
all  the  object  machines.  Self-hosting  is 
not  required,  but  is  often  desirable . 

The  DoD  operational  programming  environment  includes  many 
small  machines  which  are  unable  to  support  adequately  the  de¬ 
sign,  documentation,  test,  and  debugging  aids  necessary  for  the 
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development  of  timely,  reliable,  or  efficient  software.  Large 
machine  users  should  not  be  penalized  for  the  restrictions  of 
small  machines  when  a  common  language  is  used.  On  the  other 
hand,  the  size  of  machines  which  can  host  translators  should 
be  kept  as  small  as  possible  by  avoiding  unnecessary  general¬ 
ity  in  the  language. 

L6 ,  The  translator  vill  do  full  surtax  cheoking ^ 
will  check  all  operations  and  parar:,'  tcrs  for 
type  conpatibilitu ,  and  will  verifg  that  all 
language-i-nroscd  semantic  res  trie  t  i  ons  cn  the 
source  programs  are  met.  It  will  rot  automat- 
icallu  correct  errors  detected  at  'crrile  time. 

The  purpose  of  source  language  redundancy  and  avoidance 
of  error-prone  language  features  is  re  liar  1 2 i t y .  The  price  is 
paid  in  programmer  inconvenience  in  having  to  specify  his  in¬ 
tent  in  greater  detail.  The  payoff  comes  when  the  translator 
checks  that  the  source  program  Is  internally  consistent  and 
adheres  to  its  authors'  stated  intentions.  There  is  a  clear 
trade-off  between  error  avoidance  and  programming  ease;  sur¬ 
veys  conducted  by  the  Services  show  that  the  programm.ers  as 
well  as  managers  will  opt  for  error  avoidance  over  ease  when 
given  the  choice.  The  sane  choice  is  dictated  ty  the  need  for 
well-documented,  rr,alntalnable  software. 

L7 .  The  translator  will  produce  compile  time 
explanatory  diagnostic  error  and  warning 
messages .  A  suggested  set  of  error  and 
Warning  situations  will  be  provided  as 
part  of  the  language  definition . 

The  translator  will  attempt  to  provide  the  miaximal  use¬ 
ful  feedback  to  its  user.  Diagnostic  messages  will  not  be 
coded,  but  will  be  explanatory  and  in  source-language  terms. 
Translccors  will  continue  processing  and  checking  after  errors 
have  been  found,  but  should  be  careful  not  to  generate  erroneous 


130 


messages  because  of  translator  confusion.  The  translator  will 
always  produce  correct  code;  when  source  program  errors  are  err- 
countered  by  the  translator  or  referenced  program  structures 
omitted,  the  compiler  will  produce  code  to  cause  a  run-time 
exception  condition  upon  any  attempt  to  execute  those  parts  of 
the  program.  Warnings  will  be  generated,  when  a  source-langu¬ 
age  construct  is  exceptionally  expensive  to  implement  on  the 
specified  object  machine.  A  suggested  set  of  diagnostic  mes¬ 
sages,  provided  as  part  of  the  language  definition,  contribute! 
to  commonality  in  the  implementation  and  use  of  the  language. 
The  discipline  of  designing  diagnostic  messages  keyed  to  the 
design  may  also  uncover  pitfalls  in  the  language  design  and 
thereby  contribute  to  a  more  precise  and  better-understood 
language  description. 

L8.  The  ohavaatevistics  of  translator  imple¬ 
mentations  will  not  be  dictated  by  the 
language  definition  or  standards. 

The  adoption  of  a  common  language  is  a  commitment  to  the 
current  state  of  the  art  for  programming  language  design  for 
some  duration.  It  does  not,  however,  prevent  access  to  new 
software  and  hardware  technology,  new  techniques,  and  new  man¬ 
agement  strategies  which  do  not  have  an  impact  on  the  source 
language  definition.  In  particular,  innovation  should  be  en¬ 
couraged  in  the  development  of  translators  for  a  common  lang¬ 
uage,  providing  they  implement  exactly  the  source  language  as 
defined.  Translators,  like  all  computer  programs,  should  be 
written  in  expectation  of  change. 

L9 ,  Translators  for  the  language  will  be 
written  in  their  own  source  language . 

There  will  be  at  least  one  implementation  of  the  transla¬ 
tor  in  its  own  language  which  does  all  parsing  and  compile-tir.f 
checking  and  produces  an  output  suitable  for  easy  translation 
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to  specific  object  machines.  If  the  languape  is  well-defined 
and  uniform  in  structure,  a  self-description  will  contribute 
to  understanding  of  the  language.  The  availability  of  the 
machine-independent  portion  of  a  translator  will  make  the  full 
power  of  the  language  available  to  any  object  machine  at  the 
cost  of  producing  an  additional  code  generator  (whose  cost  may 
be  high)  and  it  reduces  the  likelihood  of  incompatible  im.ple- 
mentations.  Translators  written  in  their  own  source  lanpuare 
are  automatically  available  on  any  of  their  object  machines, 
providing  the  object  machine  has  sufficient  resources  to  sup¬ 
port  a  compiler. 

C.  LANGUAGE  DEFINIIION,  STANDARDS,  AND  CONTROL 

Ml.  The  language  will  be  conpcsed  fror  fea¬ 
tures  which  are  within  the  state  of  the 
art  and  any  design  or  redesign  which  is 
necessary  to  achieve  the  needed  charac¬ 
teristics  will  be  conducted  as  an  engi¬ 
neering  design  effort  and  not  as  a  re¬ 
search  project. 

The  adoption  of  a  common  language  can  be  successful  only 
if  it  makes  available  a  modern  programming  lanpuae:e  compati¬ 
ble  with  the  latest  software  technology  and  with  "best"  cur¬ 
rent  programming  practice,  but  the  design  and  implementation 
of  the  language  should  not  require  additional  research  or  use 
of  untried  ideas.  State  of  the  art  cannot,  however,  be  taken 
to  mean  that  a  feature  has  been  incorporated  In  an  operational 
DoD  language  and  used  for  an  extended  period,  or  DoD  will  be 
forever  tied  to  the  technology  of  FORTRAN-like  languages;  but 
there  must  be  some  assurances  through  analysis  and  use  that 
its  benefits  and  deficiencies  are  known.  The  larger  and  more 
complex  the  structure,  the  more  analysis  and  use  that  should 
be  required.  Language  design  should  parallel  other  engineer¬ 
ing  design  efforts  in  that  it  is  a  task  of  consolidation 
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and  not  innovation.  The  language  designer  should  he  familiar 
with  the  many  choices  in  semantic  and  syntactic  features  of 
language  and  should  strive  to  compose  the  best  of  these  into 
a  consistent  structure  congruous  with  the  needed  characteris¬ 
tics.  The  language  should  be  composed  from  known  semantic 
features  and  familiar  notations,  but  the  use  of  a  proven  fea¬ 
ture  should  not  necessarily  impose  that  notation.  The  lang¬ 
uage  must  not  Just  be  a  combination  of  existing  features  which 
satisfy  the  individual  requirements,  but  must  be  held  together 
by  a  consistent  and  uniform  structure  wnich  acts  to  minimize 
the  number  of  concepts,  consolidates  divergent  features,  and 
simplifies  the  whole. 

M2.  The  eemantics  cf  the  language  will  be  de¬ 
fined  unambiguously  and  clearly.  To  the 
extent  a  formal  definition  assists  in  at¬ 
taining  these  objectives 3  the  language's 
semantics  will  be  specified  formally. 

A  complete  and  unambiguous  definition  of  a  common  langu¬ 
age  is  essential.  Otherwise,  each  translator  will  resolve  the 
ambiguities  and  fill  in  the  gaps  in  its  own  unique  way.  There 
are  currently  a  variety  of  methods  for  formal  specification 
of  programming  language  semantics,  but  it  remains  a  major  ef¬ 
fort  to  produce  a  rigorous,  formal  description,  and  the  re¬ 
sulting  products  are  of  questionable  practical  value.  The 
real  value  in  attempting  a  formal  definition  is  that  it  re¬ 
veals  Incomplete  and  ambiguous  specifications.  An  attempt  will 
be  made  to  provide  a  formal  definition  of  any  language  selected, 
but  success  in  that  effort  should  not  be  requisite  to  its  se¬ 
lection.  Formal  specification  of  the  language  might  take  the 
form  of  an  axiomatic  definition,  use  of  the  Vienna  Definition 
Language,  or  use  of  some  other  formal  semantic  system. 


133 


M2,  The  user  documentation  of  the  langu~ 
age  will  be  complete  and  will  include 
both  a  tutorial  introductory  descrip¬ 
tion  and  a  formal  in-depth  description. 

The  language  will  be  defined  as  if  it 
were  the  machine-level  language  of  an 
abstract  digital  computer.  *' 

The  language  should  be  intuitively  correct  and  easily 
learned  and  understood  by  its  potential  users.  The  language 
definition  might  include  an  Algol-60-llke  description  (Ref.  1C) 
with  the  source  language  syntax  given  in  BNF  or  some  other 
easily  understood  metalanguage  and  the  corresponding  semantics 
given  in  English.  As  with  the  descriptions  of  digital  compu¬ 
ter  hardware,  the  semantics  and  syntax  of  each  feature  must  be 
defined  precisely  and  unambiguously.  The  action  of  any  legal 
program  will  be  determinable  from  the  program  ard  the  language 
description  alone.  Any  computation  which  can  be  described  in 
the  language  will  ultimately  draw  only  on  capabilities  built- 
into  the  language.  No  characteristics  of  the  source  language 
will  be  dependent  on  the  Idiosyncrasies  of  its  translators. 


The  language  documentation  will  include  syntax,  semantics, 
and  examples  of  each  language  construct,  listings  of  all  key 
words  and  language-defined  defaults.  Examples  shall  be  included 
to  show  the  intended  use  of  language  features  and  to  illustrate 
proper  use  of  the  language.  Particularly  expensive  and  inexpen¬ 
sive  constructs  will  be  pointed  out.  Each  document  will  iden¬ 
tify  its  purpose  and  prerequisites  for  its  use. 

M4 .  The  language  will  be  configuration-man¬ 
aged  throughout  its  total  life  cycle  and 
will  be  controlled  at  the  DoD  level  to 
ensure  that  there  is  only  one  version  of 
the  source  language  and  that  all  transla¬ 
tors  conform  to  that  standard. 
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without  controls,  a  comnon  language  may  become  another 
umbrella  under  which  new  languages  proliferate  while  retain¬ 
ing  the  common  language’s  name.  All  compilers  will  be  tested 
and  certified  for  conformity  to  the  standard  specification  and 
freedom  from  known  errors  prior  to  their  release  for  use  In 
production  projects.  The  language  manager  will  be  on  the  OSD 
staff,  but  a  group  within  the  Military  Departments  or  Agencies 
might  act  as  the  executive  agent.  A  configuration  control 
board  will  be  Instituted  with  user  representation  and  chaired 
by  a  member  of  the  OSD  staff. 

A/5.  There  will  be  identified  support  agentis) 

responsible  for  maintaining  the  translators 
and  for  associated  design,  development ,  de¬ 
bugging,  and  maintenance  aids. 

Language  commonality  Is  an  essential  step  In  achieving 
software  commonality,  but  the  real  benefits  accrue  when  pro¬ 
jects  and  contractors  can  draw  on  existing  software  with  as¬ 
surance  that  It  will  be  supported,  when  systems  can  build  from 
off-the-shelf  components,  or  at  least  with  common  tools,  and 
when  efforts  can  be  expended  In  expanding  existing  capabilit¬ 
ies  Instead  of  building  from  scratch.  Support  of  common,  widely 
used  tools  and  aids  should  be  provided  independently  of  pro¬ 
jects  if  common  software  Is  to  be  widely  used.  Support  should 
be  on  a  DoD-wlde  basis,  with  final  responsibility  resting  with 
a  stable  group  or  groups  of  qualified  in-house  personnel. 

M6.  There  will  be  standards  and  support  agents 

for  common  libraries ,  including  application- 
oriented  libraries . 

In  a  given  application  of  a  programming  language,  three 
levels  of  the  system  must  be  learned  and  used:  the  base  lang¬ 
uage,  the  standard  library  definitions  used  in  that  application 
area,  and  the  local  application  programs.  Users  are  responsi¬ 
ble  for  the  local  application  programs  and  local  definitions. 
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but  not  for  tin'  lanruaro  nr.d  its  llbrarlt-s,  which  are  used  iy 
many  projects  nnd  sites.  A  principal  user  rlrlu  act.  as  arcr.r 
for  an  entire  application  area. 
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ARMY 


U.S.  Army  Aviation  Systems  Command 
St.  Louis,  MO 

U.S.  Army  B.R.I. 

U.S.  Army  Communications  Command 
Ft.  Huachuca,  AZ  85613 

U.S.  Army  Computer  Systems  Command 
Ft.  Belvoir,  VA  22060 

U.S.  Army  Electronics  Command 
Ft.  Monmouth,  NJ  07703 

Atmospheric  Sciences  Laboratory 
White  Sands  Missile  Range,  NM  88002 

Comrri/Int  Tech.  Area  EW  Lab 

Computer  Hardware  Tech  Area 

Electronics  Tech  and  Devices  Lab 

Night  Vision  Laboratory 
Ft.  Belvoir,  VA  2206C 

Radar  Tech  Area  CS&TA  Lab 

Systems  and  Programming  Division 

Switching  Tech  Area 

U.S.  Army  Force  Development  Command 
Ft.  McPherson,  GA  30330 

U.S.  Army  Intelligence  Center  and  School 
Ft.  Huachuca,  AZ  85613 

U.S.  Army  Material  Command 
Ft.  Monmouth,  NJ  07703 
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Army  Tactical  Communications  Systems 
Airniy  Tactical  Data  Systems 
Navigation/Control  Systems 

Remotely  Monitored  Battlefield  Sensor  System 

U.S.  Army  Mobility  Equipment  Research  and  Development  Center 
Ft.  Belvoir,  VA  22060 

U.S.  Army  Tank-Automotive  Coimricind 
Warren,  MI  48090 

U.S.  Army  Test  and  Evaluation  Command 
Aberdeen  Proving  Grounds,  MD  21005 

U.S.  Army  Training  and  Doctrine  Command 
Ft.  Monroe,  VA  23651 

U.S.  Army  Training  Support  Activity 
Ft.  Eustis,  VA  23604 

*  ^ 

U.S.  Army  Troop  Support  Command 
4300  Goodfellow  Blvd 
St.  Louis,  MO  63166 

U.S.  army  Security  Agency,  Management  Information  Systems 
Arlington  -Hall  Sta^^ion 
Arlington,  VA  22212 

U.S.  Army  White  Sands  Missile  Range 
White  Sands  Missile  Range,  NM  88002 

Ballistic  Missile  Defense  Project  Office 
1300  Wilson  Blvd 
Arlington,  VA  22209 

Frankford  Arsenal 
Philadelphia,  PA  19137 

Harry  Diamond  Laboratories 
2800  Powder  Mill  Road 
Adelphi,  MD  20783 

Modern  Army  Selected  Systems  Test  Evaluation  and  Review 
Ft.  Hood,  TX  765^^ 

Office  of  Chief  of  Engineers 
Washington,  DC  20314 


A- 4 


Office  of  Chief  of  Staff 
Washington,  DC  20314 

Office  of  Chief  of  Staff  for  Intelligence 
Washington,  DC  20310 

Office  of  the  Surgeon  General 
Washington,  DC  20310 

Plcatlnny  Arsenal 
Dover,  NJ  07801 

Redstone  Arsenal 
Redstone  Arsenal,  AL  3580'^ 

NAVY 


Naval  Air  Development  Center 
Warminister,  PA  18974 

Naval  Air  Systems  Command 
Washington,  DC 

Naval  Air  Engineering  Center 
Lakehurst ,  NJ 

Naval  Air  Test  Center 
Patuxent  River,  MD  20670 

Naval  Electronic  Systems  Test  and  Evaluation  Detachment 
Patuxent  River,  MD  20670 

Office  of  the  Oceanographer  of  the  Navy 
Alexandria,  VA  22332 

ASW  Systems  Project  Office 
National  Center  Bldg  #1 
Arlington,  VA 

United  States  Naval  Academy 
Annapolis,  MD  21402 

Naval  Undcrwatei  Systems  Center 
New  London,  CT  06350 

Naval  Underwater  Systems  Center  Headquarters 
Newport,  RI  02640 


Naval  Undersea  Center 
San  Diego,  CA  92132 


Naval  Surface  Weapons  Center  Headquarters 
White  Oak,  Silver  Spring,  MD  20910 

Naval  Surface  Weapons  Center,  Dahlgren  Laboratory 
Dahlgren,  VA 

David  W.  Taylor  Naval  Ship  R&D  Center 

Naval  Ship  Research  and  Development  Center  HQS. 

Bethesda,  MD  2003^4 

Naval  Sea  Systems  Command 
Washington,  DC  20362 

Fleet  Combat  Direction  Systems  Support  Activity 
Virginia  Beach,  VA  23^61 

Fleet  Combat  Direction  Systems  Support  Activity 
San  Diego,  CA  921^)7 

Naval  Material  Command 

Naval  Electronics  Laboratory  Center 
San  Diego,  CA 

Naval  Intelligence  Command 

Naval  Postgraduate  School 
Monterey,  CA 

Naval  Research  Laboratory 
Washington,  DC 

Naval  Weapons  Center 
China  Lake,  CA 

AIR  FORCE 


Aerospace  Defense  Command 
Ent  AFB,  CO  80912 

Air  Force  Accounting  and  Finance  Center 
Denver,  CO  80205 

Air  Force  Audit  Agency 
Norton  AFB,  CA  92^40° 

Air  Force  Communications  Service 
Richards  Gebaur  AFB,  MO  6^4030 

Air  Force  Data  Automation  Agency 
Gunter  AFB,  AL  3611^ 


Air  Force  Intelligeiice  Service 
Washington,  DC  20330 

Air  Force  Logistics  Command 
Wrlght-Patterson  AFB,  OH  A5A33 

Air  Force  Military  Personnel  Center 
Randolph  AFB,  TX  781^8 

Air  Force  Systems  Command 
Andrews  AFB,  Washington,  DC 

Aeronautical  Systems  Division  ASD/RWSV 
Wrlght-Patterson  AFB,  OH  ^5**33 

Air  Force  Avionics  Laboratory 
Wrlght-Patterson  AFB,  OH  '*5'*33 

Armament  Development  and  Test  ADTC/TSX  Center 
Eglin  AFB,  FL  325^2 

Directorate  of  Computer  Resource  Development, 
Policy  8c  Planning 
AFSC/XRF 

Andrews  AFB,  Washington,  DC 

Electronic  Systems  Division 
ES D/MCI 

L.  G.  Hanscom  AFB,  MA  01730 

Rome  Air  Develooment  Center 
RADC/I3I 

Grifflss  AFB,  NY  13^-a 

Space  and  Missile  Systems  Organisation 
SAMSO/DYVC 

Los  Angeles,  CA  90009 

Air  Force  Test  and  Evaluation  Center 
Kirtland  AFB,  NM  87115 

Air  Training  Command 
Randolph  AFB,  TX  781^8 

Air  University 
Maxwell  AFB,  AL  36II2 

Alaskan  Air  Command 
APO  Seattle,  WA  987^2 
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fnllltary  Airlift  Command 
Ccott  AFB,  IL  62225 

Strategic  Air  Command 
Offutt  AFB,  NE  68113 

Tactical  Air  Command 
Langley  AFB,  VA  23665 

United  States  Air  Force  Academy 
USAF  Academy,  CO  808A0 

United  States  Air  Force  Security  Service 
San  Antonio,  TX  782^43 

INDUSTRY 

Aerospace  Corporation 

Boeing  Aerospace  Company 

Bolt,  Beranek,  and  Newman,  Inc. 

Burroughs  Corporation 

Charles  Stark  Draper  Laboratory,  Inc- 

Computer  Sciences  Corporation 

General  Electric  Company 

Grumman  Aerospace  Corporation 

ilughes  Aircraft  Company 

intermetrl cs ,  Inc. 

International  Business  Machines  Corporation 
Litton  Systems,  Inc. 

Massachusetts  Computer  Associates,  Inc. 
McDonnell  Dov>glas  Astronautics  Company 
Mellanlcs 

Research  and  Consulting,  Inc. 
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Rolm  Corporation 


Scientific  Applications,  Inc. 

Singer  Company 
Sof  Tech 
Sperry  Univac 
Systems  Control,  Inc. 

Texas  Instrument  Company 
TRW  Systems  Group 

Westinghouse  Defense  and  Electronics  Systems  Center 
Xerox  Palo  Alto  Research  Center 
OTHER  ORGANIZATIONS  AND  INDIVIDUALS 


Defense  Advanced  Research  Projects  Agency 
Washington,  DC 

Defense  Communications  Agency 
Washington,  DC 

Lawrence  Livermore  Laboratory 
University  of  California 
Livermore,  CA 

National  Aeronautics  And  Space  Administration 
Washington,  DC 

James  J.  Besemer 
Purdue  University 
West  Lafayette,  IN 

Thomas  E.  Cheatham,  Jr. 

Harvard  University 
Cambridge,  KA 

Richard  A.  DeMillo 

University  of  Wis consln-Milwaukee 

Milwaukee,  WI 

Edsger  W.  Dljkstra 
Nuenen,  The  Netherlands 

Philip  H.  Enslow 

Georgia  Institute  of  Technology 

Atlanta,  GA 


David  Cries 
Cornell  University 
Ithica,  NY 

C.A.R.  Hoare 

Queen's  University  of  Belfast 
Belfast,  Northern  Ireland 

Richard  A.  Karp 
"t,.  nford  University 
Csanford,  CA 

Peter  T.  Kirstein 
University  College  London 
London,  England 

Henry  F,  Ledgard 
University  of  Massachusetts 
Ar.herst,  KA. 

Ralph  L.  London 

Information  Sciences  Institute 
University  of  California 
Marina  del  Ray,  CA 

Stuart  Madnick  and  Leonard  Goodman 

Sloan  School,  Massachusetts  Institute  of  Technology 

Cambridge,  HA 

John  McCarthy 

Artificial  Intelligence  Laboratory 
Stanford  University 
Stanford,  CA 

Jacob  Palme 

Swedish  National  Defense  Research  Institute 
Stockholm,  Sweden 

Ian  C.  Pyle 
laiivorslty  of  York 
Heslington,  York,  England 

Thomas  A.  Standish 
University  of  Callfornia-Irvine 
Irvine,  CA 

J.T.  Webb 

Royal  Radar  Establishment 
Malvern,  Great  Britain 


''.A.  Wlchmann 

.ational  Physics  Laboratory 
-eddington ,  Middlesex,  United  Kingdom 

William  A,  Wulf 
Carnegie  Mellon  University 
Pittsburgh,  PA 
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